[Cisco] Vraag over Transparante firewall met 2xFe en 1 BVI

[Roel Broersma]

Hallo,

Vorige week is er hier een nieuwe internet verbinding met een /27 (32 ip's) opgeleverd.
De provider beheerd de Juniper router met IP: 213.x.x.1 en daar kunnen we zelf dus niets mee.

Achter de Juniper router heb ik een Cisco 2811 aangesloten die dienst gaat doen als Firewall. De router heeft 2x een FastEthernet Interface. Die heb ik in een bridge-group gegooit.
Aan de andere kant van de Cisco Router (firewall) zit een switch waar servers op aangesloten zitten.

Nu wil ik de firewall gaan configureren (eerst simpel beginnen met een access list), maar vreemdgenoeg werken de access-lists totaal niet.

Uittreksel van de config

code:

interface FastEthernet0/0
 description Connected to the LAN network (Gigabit Switch)
 no ip address
 ip access-group 113 in
 ip virtual-reassembly
 duplex auto
 speed auto
 bridge-group 1
 !
!
interface FastEthernet0/1
 description Connected to the Juniper Router
 no ip address
 ip access-group 113 in
 ip virtual-reassembly
 duplex auto
 speed auto
 bridge-group 1
 !
!
interface BVI1
 ip address 192.168.0.253 255.255.255.0
 ip address 213.x.x.2 255.255.255.224 secondary
 ip virtual-reassembly
 !
!
access-list 113 deny   ip any any

Vreemd genoeg komt al het verkeer gewoon door, ik kan vanaf buiten (bijv. vanaf mijn mobiele telefoon met 3G) gewoon de servers pingen.

Je zou zeggen dat ik de access-list op de BVI1 moet zetten, maar dit zou 'zonde' zijn van de resources want dan wordt elk pakketje 2x gecontroleerd (wanneer het naar binnen gaat en weer terug naar buiten).

Weet iemand hier het fijne van ?

[silvans]

Waarom maak je een bridge en routeer je dit niet gewoon?
Een bridge met zowel een private als een public IP lijkt me bij een interverbinding zowieso een misconfiguratie.

Ik zou fast0/0 het 192.168.0.253 adres geven, en fast0/1 het public ip address dat je wilt gebruiken. Vervolgens een route 0.0.0.0 naar het adres van de juniper.

De bridge helemaal verwijderen, en dan kijken of je ACL gaat werken.

[Roel Broersma]

silvans schreef op maandag 27 september 2010 @ 14:18:
Waarom maak je een bridge en routeer je dit niet gewoon?
Een bridge met zowel een private als een public IP lijkt me bij een interverbinding zowieso een misconfiguratie.

Ik zou fast0/0 het 192.168.0.253 adres geven, en fast0/1 het public ip address dat je wilt gebruiken. Vervolgens een route 0.0.0.0 naar het adres van de juniper.

De bridge helemaal verwijderen, en dan kijken of je ACL gaat werken.

Ik wil de servers zowieso een eigen Public IP adres geven. Als ik er dan een router tussen zet (en ik ga routeren) dan moet ik het subnet wat ik van de provider krijg (met 32 IPs) dus opdelen in 2 subnets (van elk 16 IPs):
- 1 subnet waar de Juniper en de Fe0/1 in zit
- 1 subnet waar de servers en de Fe0/0 in zit

Of dacht je al het verkeer naar de servers te reverse-natten ?

[ Voor 3% gewijzigd door Roel Broersma op 27-09-2010 15:07 ]

[Flyduck]

Het IP adres wat je op de BVI configureert is alleen voor management toegang. Zonder IP routing en IP adres op de interface kan je volgens mij geen ACL gebruiken,...Maar ik ben niet 100% zeker want daarvoor ben ik te lang uit het configureren van Cisco

[Roel Broersma]

Flyduck schreef op maandag 27 september 2010 @ 15:42:
Het IP adres wat je op de BVI configureert is alleen voor management toegang. Zonder IP routing en IP adres op de interface kan je volgens mij geen ACL gebruiken,...Maar ik ben niet 100% zeker want daarvoor ben ik te lang uit het configureren van Cisco

Als je onderstaande globale commando's invoerd:

code:

bridge irb
bridge 1 protocol ieee
bridge 1 route ip

Dan zou het IP adres wat op de BVI1 staat wel degelijk moeten kunnen routeren.

[elTigro]

was het niet zo dat enkel 4500/6500's dat op een switchport wilden doen? (acl dus)

[Flyduck]

Roel Broersma schreef op maandag 27 september 2010 @ 15:44:
[...]


Als je onderstaande globale commando's invoerd:

code:

bridge irb
bridge 1 protocol ieee
bridge 1 route ip

Dan zou het IP adres wat op de BVI1 staat wel degelijk moeten kunnen routeren.

Ja dat klopt wel wat je zegt, je kan dan routeren naar een andere IP enabled interface, en die heb je hier niet...

[silvans]

Ik vermoed dat je op een dergelijke bridge-constructie alleen MAC-based ACL's kunt toepassen. Probeer dat eens.

[Roel Broersma]

Flyduck schreef op maandag 27 september 2010 @ 16:04:
[...]


Ja dat klopt wel wat je zegt, je kan dan routeren naar een andere IP enabled interface, en die heb je hier niet...

Die BVI1 interface is een 'hook' naar Layer3 niveau

Even terug naar het probleem: De access-lists op de FastEthernet interfaces werken niet.

Je zou zeggen: Zet de access-list op de BVI1, maar dat ik volgens mij niet de bedoeling (dan zou de access-list alleen werken als er naar een ander subnet gerouteerd zou worden).

[Flyduck]

Roel Broersma schreef op maandag 27 september 2010 @ 16:13:
[...]


Die BVI1 interface is een 'hook' naar Layer3 niveau

Even terug naar het probleem: De access-lists op de FastEthernet interfaces werken niet.

Je zou zeggen: Zet de access-list op de BVI1, maar dat ik volgens mij niet de bedoeling (dan zou de access-list alleen werken als er naar een ander subnet gerouteerd zou worden).

Als je de ACL op de BVI zet gaat dat ook niet werken. Bridging is layer 2 activiteit en als het verkeer binnen de bridge blijft wordt er niet op layer 3 gecontroleerd. Alhoewel er wel apparatuur is die het wel kan, maar weet zo snel even niet welke....

[Bloodshot]

Ik zou inderdaad de BVI weghalen en de eerste post van Silvans uitvoeren. Dat in combinatie met 1-op-1 NAT en je hebt een redelijk simpele configuratie waarbij je servers extern bereikbaar zijn.

[Roel Broersma]

Bloodshot schreef op maandag 27 september 2010 @ 16:50:
Ik zou inderdaad de BVI weghalen en de eerste post van Silvans uitvoeren. Dat in combinatie met 1-op-1 NAT en je hebt een redelijk simpele configuratie waarbij je servers extern bereikbaar zijn.

Als ik 1-op-1 NAT ga doen met de servers, dan moet ik de servers dus een private IP adres geven (laten we zeggen 192.168.0.10, etc.) en in de Router configuratie een Publiek IP adres naar het Private IP adres mappen.

Ik weet niet of ik dan problemen krijg met applicaties,.. interne/externe DNS,..etc.
Ik hou liever geen dubbele IP administratie bij, ik heb het gevoel dat ik dan niet de goede kant op ga.

[ Voor 11% gewijzigd door Roel Broersma op 27-09-2010 17:06 ]

[Roel Broersma]

Flyduck schreef op maandag 27 september 2010 @ 16:04:
[...]


Ja dat klopt wel wat je zegt, je kan dan routeren naar een andere IP enabled interface, en die heb je hier niet...

Op de cisco site: http://www.cisco.com/en/U...e/gt_trans.html#wp1027188 staat een voorbeeld van een transparante firewall (waarin met 2 Fe interfaces in een BVI zet, vervolgens access-lists op die Fe interfaces). Dat is toch exact hetzelfde?

Heel vreemd dat bij mij die access-lists op de Fe interfaces totaal geen effect hebben.

[Flyduck]

Roel Broersma schreef op maandag 27 september 2010 @ 17:08:
[...]


Op de cisco site: http://www.cisco.com/en/U...e/gt_trans.html#wp1027188 staat een voorbeeld van een transparante firewall (waarin met 2 Fe interfaces in een BVI zet, vervolgens access-lists op die Fe interfaces). Dat is toch exact hetzelfde?

Heel vreemd dat bij mij die access-lists op de Fe interfaces totaal geen effect hebben.

Zo te zien kan het inderdaad met de Cisco 2800 IOS ADVANCED IP SERVICES IOS.... heb je die wel?

[Roel Broersma]

Flyduck schreef op maandag 27 september 2010 @ 17:31:
[...]


Zo te zien kan het inderdaad met de Cisco 2800 IOS ADVANCED IP SERVICES IOS.... heb je die wel?

Ja, ik heb de laatste:
Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 15.0(1)M3, RELEASE SOFTWARE (fc2)

[ Voor 49% gewijzigd door Roel Broersma op 27-09-2010 17:53 ]

[Bloodshot]

@Roel Broersma: Als je de servers op laag 2 op Internet wilt hebben, vraag ik me af wat je precies voor firewall-functionaliteit voor de router in gedachten hebt.

[Roel Broersma]

Bloodshot schreef op maandag 27 september 2010 @ 18:29:
@Roel Broersma: Als je de servers op laag 2 op Internet wilt hebben, vraag ik me af wat je precies voor firewall-functionaliteit voor de router in gedachten hebt.

De firewall zit er als een laag2 apparaat tussen, maar kan wél gebruik maken van packet inspection en access-lists. Dat heet een Transparante Firewall. Je hoeft dan niet te routeren en je hoeft niets te veranderen aan je netwerk topologie of aan je ip-adres plan.

[Predator]

Ik weet dat je het niet graag gaat horen, maar dit is nergens voor nodig.

Bespreek dit met je provider.
Spreek een ander subnet af (een /30 bv) tussen jouw router en hun router.
Laat hun router dan je /27 routeren naar jouw /30 IP.
Daarna ben je baas op je eigen router ovet dat subnet.

Dit is geknutsel...

[ Voor 3% gewijzigd door Predator op 27-09-2010 19:25 ]

[axis]

Dit is geen geknutsel, er zijn zat grote jongens die gebruik maken van transparent firewalling, het is niet voor niets een erg belangrijke feature van de cisco ASA range.. Maar natuurlijk is routed mode vele malen makkelijker, dus klets inderdaad eens met je leverancier over de mogelijkheden..

[Roel Broersma]

Ik begrijp simpelweg niet waarom het niet werkt op een Cisco 2811. Ik pak het meest simpele voorbeeld en het werkt niet. (hij laat wel verkeer door, maar ik kan niets restricten, de ACL's doen het simpelweg niet).

Opzich is 'transparent firewalling' een normale feature en niet 'prutserig', meestal wordt er inderdaad gebruik gemaakt van Routed Firewall (veelal ook als erfenis uit de historie).

[Flyduck]

Heb je ook wat anders geprobeerd dan pingen? Want je hebt niet expliciet een deny op ICMP.

[Roel Broersma]

Flyduck schreef op maandag 27 september 2010 @ 20:45:
Heb je ook wat anders geprobeerd dan pingen? Want je hebt niet expliciet een deny op ICMP.

Ik heb later nog wel expliciet een deny op ICMP gezet. Ook heb ik naar de access-list gekeken met "show access-list 113" om te kijken of er matches waren.
Ik heb ook nog even "permit ip any any" erin gezet om te kijken of er dan wel matches komen op die regel... helaas..
Ik heb ook nog een webserver opgezet en op poort 80 en wat geprobeerd. Allemaal geen success en geen matches op de acces-list.

[Flyduck]

Op die link die je gepost had staat het volgende;

Only IP packets (TCP, User Datagram Protocol [UDP] , and Internet Control Message Protocol [ICMP]) are subjected to inspection by the transparent firewall

Ze hebben het dus over inspection en niet over packet filtering. Je zou kunnen testen of ip inspect wel werkt.

[Roel Broersma]

Flyduck schreef op maandag 27 september 2010 @ 21:21:
Op die link die je gepost had staat het volgende;

Only IP packets (TCP, User Datagram Protocol [UDP] , and Internet Control Message Protocol [ICMP]) are subjected to inspection by the transparent firewall

Ze hebben het dus over inspection en niet over packet filtering. Je zou kunnen testen of ip inspect wel werkt.

Ik ben inderdaad nog niet eens aan het testen van "ip inspect" toegekomen omdat ik eerst de access-lists werkende wou hebben.
Aan alleen "ip inspect" heb ik niets want daarmee kan ik nog geen poorten dicht zetten (en open staan ze nu toch al... dus er hoeft niets 'extra' open te worden gezet, dat is hetgeen waarvoor ip inspect o.a. voor wordt gebruikt: Als statefull firewall )

Op diezelfde pagina zet men ook de "ip access list" op de FastEthernet interfaces en maakt men een access-list aan (CTRL-F "access-list" ).

[Bloodshot]

Roel Broersma schreef op maandag 27 september 2010 @ 20:12:
Ik begrijp simpelweg niet waarom het niet werkt op een Cisco 2811. Ik pak het meest simpele voorbeeld en het werkt niet. (hij laat wel verkeer door, maar ik kan niets restricten, de ACL's doen het simpelweg niet).

Opzich is 'transparent firewalling' een normale feature en niet 'prutserig', meestal wordt er inderdaad gebruik gemaakt van Routed Firewall (veelal ook als erfenis uit de historie).

Ik weet dat transparent firewalling normaal is. Ik weet niet of het veel gebruikt wordt. In de praktijk en op cursussen (Cisco/Checkpoint) ben ik het nog niet of nauwelijks tegengekomen. Wellicht een domme vraag: Ondersteund een 2811 dit wel?

[Predator]

axis schreef op maandag 27 september 2010 @ 19:59:
Dit is geen geknutsel, er zijn zat grote jongens die gebruik maken van transparent firewalling, het is niet voor niets een erg belangrijke feature van de cisco ASA range.. Maar natuurlijk is routed mode vele malen makkelijker, dus klets inderdaad eens met je leverancier over de mogelijkheden..

Dit is wel geknutsel

Het feit dat er wel scenarios zijn waar transparent firewalling nuttig kan zijn, verandert daar niets aan.
Dit is er namelijk geen van. Dan neem je trouwens ook geen 2811 router daarvoor

Dit is het ontwijken van de evidente simpele oplossing, die al deze morgen perfect zou gewerkt hebben ... met die 2811 router op 5 minuten

[Flyduck]

Probeer het eens op deze manier

At this point, you now have a bridge group. The configuration and status can be seen with the command show bridge-group. Next, we must configure some inspection rules. We’ll enable inspection for TCP on ethernet0, and then configure an ACL.

Router(config)# ip inspect name test tcp
Router(config)# interface ethernet0
Router(config-if)# ip inspect test in

Now, some sort of access-list needs to be created before we can enable it on the Layer 2 interface.

Router(config)# access-list 101 permit host 10.0.0.51 any any
Router(config)# access-list 101 deny ip any any
Router(config)# access-list 102 permit 10.0.0.0 0.0.0.255 any
Router(config)# access-list 102 permit tcp any any eq ssh
Router(config)# access-list 102 deny ip any any

We’ve created two, actually. List 101 will be applied to the external interface, and is configured to allow outside people to talk to host 10.0.0.51 (assuming the ACL is applied “in” on the interface). List 102 is configured to allow only SSH outbound from inside the 10.0.0.0/24 network.

Now we simply need to apply the ACL to the Layer 2 interfaces:

Router(config)# interface ethernet0
Router(config-if) ip access-group 102 in
Router(config)# interface ethernet1
Router(config-if) ip access-group 101 in

Misschien moet je gewoon ip inspect name xxx tcp gebruiken om de L3 functie te activeren.

If inspection is not configured on any interface in a bridge group, the IP ACL on the BVI is not active

[ Voor 3% gewijzigd door Flyduck op 27-09-2010 22:05 ]

[pablo_p]

Ik heb wel ervaring met een transparante firewall, die helemaal naar wens werkte, maar dat was dus met een Cisco PIX en ASA. Een ASA 5510 is niet zo heel duur, is het een optie die er tussenin te plaatsen ipv een 2811? Heb je ook veel meer performance.

Als je het eerst wil testen, kan je er een PIX tussenplaatsen (voorloper van de ASA). Modellen 515/515E/525/535 ondersteunen versie 7.x en hoger en daarmee transparante firewall en zijn makkelijk ergens te vinden. Ik vind een ASA/PIX sowieso een veel betere keuze dan een route voor firewalling, stukken eenvoudiger en die devices zijn ook primair gebouwd voor firewalling ipv routering.

[ Voor 3% gewijzigd door pablo_p op 28-09-2010 08:04 ]

[Roel Broersma]

Predator schreef op maandag 27 september 2010 @ 22:01:
[...]

Dit is wel geknutsel

Het feit dat er wel scenarios zijn waar transparent firewalling nuttig kan zijn, verandert daar niets aan.
Dit is er namelijk geen van. Dan neem je trouwens ook geen 2811 router daarvoor

Dit is het ontwijken van de evidente simpele oplossing, die al deze morgen perfect zou gewerkt hebben ... met die 2811 router op 5 minuten

Ik ben ondertussen aan het onderhandelen met mijn Provider, ik heb ze zojuist gebeld en toen zei men: "Zet het even op mail". Ik hoop dat men reageerd en dat ze welwillend zijn, zo niet, dan zal ik hier het mailtje posten.

Ondertussen probeer ik de ip inspect oplossing zoals FlyDuck zegt, ik ben echt reuze benieuwd of dat het probleem is: "the acl is not activated zolang er geen ip inspect op staat". Je hoort zometeen meer!

[Flyduck]

Nou je hebt nu tijd genoeg gehad om te testen .... werkt het?

[Roel Broersma]

Flyduck schreef op dinsdag 28 september 2010 @ 14:40:
Nou je hebt nu tijd genoeg gehad om te testen .... werkt het?

Ja dat werkt!! Thanks! Je gaat er niet vanuit omdat je denk dat het al direct werkt.. Maar je moet toch echt eerst de ip inspect aanzetten.

Thanks again!

[ Voor 48% gewijzigd door Roel Broersma op 04-11-2010 11:49 ]