[CISCO PIX] Extra subnet op zelfde interface ?

[Verwijderd]

Ik ga lekker door met ijn Pix, het gaat redelijk gestaag !

Ik draai nu een 192.168.1.0 reeks op de inside en een default 0.0.0.0 0.0.0.0 route naar buiten toe, mijn interne hosts kunnen dus naar buiten met een NAT waarbij het outside adres van de Pix gebruikt wordt.

Nu wil ik eigenlijk nog een subnet op de pix draaien voor andere hosts, namelijk een 10.0.0.0 reeks. Dit lijk alleen niet zo makkelijk als het eruit ziet.

Ik heb een logical vlan aangemaakt op de inside en deze vlan een 10.0.0.254 adres gegeven, dit zou ik als gateway willen gebruiken voor de 10.x reeks. Wanneer ik een host met 10.0.0.253 de 10.0.0.254 wil laten pingen kan dit niet, de 10.0.0.253 host zegt dat de Host Unreachable is.

Dit zou simpel weg kunnen komen door de access-list, maar ik vraag mij eigenlijk wat anders af.

Is het niet gewoon simpeler om er een extra NIC voor de 10.x reeks in te zetten ?

[Verwijderd]

Het blijkt dat het makkelijker is om een extra NIC in de PIX te zetten voor het extra subnet.

Toch vraag ik mij af wanneer de Cisco guru's beweren dat wanneer ik een 192.168.1.0 range aan de binnenkant van mijn PIX gebruik, waar 192.168.1.254 mijn gateway dus is, en daar 10.0.0.x hosts achter hang met als gateway 192.168.1.254 dat deze 10.0.0.x host gewoon naar buiten moeten kunnen communiceren met de default route.

Mijn 10.0.0.x hosts krijgen niet eens een defautl gateway in de routetabel, dus dat lijkt me niet goed.

De vlan zal bijvoorbaar natuurlijk afgeschermd zijn van de rest van de subnets die erop draaien. Ik vraag me eigenlijk af of het wel haalbaar is om meerdere subnets op een simpele manier hierop te draaien.

[recharge]

Verwijderd schreef op dinsdag 26 december 2006 @ 13:17:
Toch vraag ik mij af wanneer de Cisco guru's beweren dat wanneer ik een 192.168.1.0 range aan de binnenkant van mijn PIX gebruik, waar 192.168.1.254 mijn gateway dus is, en daar 10.0.0.x hosts achter hang met als gateway 192.168.1.254 dat deze 10.0.0.x host gewoon naar buiten moeten kunnen communiceren met de default route.

Mijn 10.0.0.x hosts krijgen niet eens een defautl gateway in de routetabel, dus dat lijkt me niet goed.

De vlan zal bijvoorbaar natuurlijk afgeschermd zijn van de rest van de subnets die erop draaien. Ik vraag me eigenlijk af of het wel haalbaar is om meerdere subnets op een simpele manier hierop te draaien.

- Ondersteunt je switch trunk-poorten ? (om VLAN info te transporteren tussen je PIX's inside-interface en je switch ?)

- Nee een 10.0.0.x (/24?) host kun je nooit voorzien van een 192.168.1.254 default gateway. De default gateway van een host moet altijd in hetzelfde subnet (vd host) zitten.
Waar je naar toe wil is het gebruik van NAT statements om het 10.0.0.x verkeer te "NAT'ten" als dat verkeer het internet op wil (hide je 10.0.0.x IP-adressen achter het public IP op je outside interface)

Google eens wat rond m.b.t. NAT en Cisco PIX ...
http://www.cisco.com/en/U...ote09186a00800b6e1a.shtml

[Verwijderd]

recharge schreef op dinsdag 26 december 2006 @ 17:54:
[...]


- Ondersteunt je switch trunk-poorten ? (om VLAN info te transporteren tussen je PIX's inside-interface en je switch ?)

Waat het geheel nu aanhangt niet, ik heb er nog wel een paar denk ik.

- Nee een 10.0.0.x (/24?) host kun je nooit voorzien van een 192.168.1.254 default gateway. De default gateway van een host moet altijd in hetzelfde subnet (vd host) zitten.
Waar je naar toe wil is het gebruik van NAT statements om het 10.0.0.x verkeer te "NAT'ten" als dat verkeer het internet op wil (hide je 10.0.0.x IP-adressen achter het public IP op je outside interface)

Google eens wat rond m.b.t. NAT en Cisco PIX ...
http://www.cisco.com/en/U...ote09186a00800b6e1a.shtml

Dat dacht ik dus ook al.

Ik heb al uren gegoogled, niet op nat trouwens, maar het vreemde is dat ik intern niet tussen de 10.0.0.0 hosts kan pingen. Hier zal dus ook een access-list voor aangemaakt moeten worden ?

[recharge]

Verwijderd schreef op dinsdag 26 december 2006 @ 18:53:
[...]


Waat het geheel nu aanhangt niet, ik heb er nog wel een paar denk ik.


[...]


Dat dacht ik dus ook al.

Ik heb al uren gegoogled, niet op nat trouwens, maar het vreemde is dat ik intern niet tussen de 10.0.0.0 hosts kan pingen. Hier zal dus ook een access-list voor aangemaakt moeten worden ?

-Als je informatie mbt meerdere VLAN's via je inside-interface naar je LAN stuurt (via 1 touwtje) , zal de switch gekoppeld aan de inside interface overweg MOETEN kunnen met een trunk-port definitie.
(Aangezien we het over het merk Cisco hebben. Een switchpoort op een Cisco switch zal zich "default" zich gedragen als lid van 1 VLAN. (switchport mode access).


-intern tussen hosts pingen ....
Als je pingt van 10.0.0.A /24 naar 10.0.0.B /24 (en je dus in jouw geval in hetzelfde subnet blijft); heeft een ACL op de PIX er niks mee te maken. Dat verkeer zal niet via de PIX lopen, maar zal het dataverkeer netjes via je switch(es) lopen.

Het lijkt me slim om er eerst voor te zorgen dat je wat systematischer stap voor stap dingen gaat proberen aan de praat te krijgen
Eigen subnet / binnen 1 VLAN:
- Stap 1 Begin bijvoorbeeld eerst eens met statische IP-adressen in de 10-reeks; zorg dat je onderling kunt pingen. werkt het ? -> Stap 2
- Stap 2; krijg je het aan de praat met DHCP? Werkt dat ?

Buiten je subnet:
- Stap 3; kijk of je routering / NAT tussen je 192.168.1.x en 10.0.0.x range aan de praat kunt krijgen
(Let op je VLAN defintie's / ACL's) werkt dat ?
- Stap 4: ga stoeien met NAT translatie m.b.t. je internet connectie
etc.

(boodschap: Bouw het stap voor stap op en probeer niet ineens een niet-werkende VLAN omgeving te troubleshooten)

Mag ik je als tip meegeven dat het geen kwaad kan om naast een " PIX/NAT Google-zoektocht" ook je (nog) eens te verdiepen in subnetting/werking van IP routering in algemeenheid ?
Wellicht vallen, na het lezen van wat white-papers, de puzzelstukjes dan wat sneller op z'n plaats

Happy troubleshooting !

[Verwijderd]

Dank je !

Het stappenplan ben ik zeker mee bezig, ik heb een aantal zaken op die manier ook goed werkend gekregen. Je wil alleen de werkende situaties niet op hun gat helpen door zaken die je ook wil testen/weten in de werkende situatie te gooien

Ik ga dat NATTEN nog wel even nazoeken, en post hier zodra er hulp benodigd is

[Verwijderd]

recharge schreef op dinsdag 26 december 2006 @ 19:51:
[...]


-Als je informatie mbt meerdere VLAN's via je inside-interface naar je LAN stuurt (via 1 touwtje) , zal de switch gekoppeld aan de inside interface overweg MOETEN kunnen met een trunk-port definitie.
(Aangezien we het over het merk Cisco hebben. Een switchpoort op een Cisco switch zal zich "default" zich gedragen als lid van 1 VLAN. (switchport mode access).

Bedoel je nu dat ik vlans op de switch zal moeten gebruiken met meerdere nics op de PIX eigenlijk ? Dit zou makkelijker moeten zijn.

-intern tussen hosts pingen ....
Als je pingt van 10.0.0.A /24 naar 10.0.0.B /24 (en je dus in jouw geval in hetzelfde subnet blijft); heeft een ACL op de PIX er niks mee te maken. Dat verkeer zal niet via de PIX lopen, maar zal het dataverkeer netjes via je switch(es) lopen.

Klopt, ik was met een vpn aan het connecten, die komt volgens de pix van buitenaf... Trouwens tussen hosts aan de binnenkant ging dit ook met 10.10.1.x op de 2e nic, gateway probleem ?

Het lijkt me slim om er eerst voor te zorgen dat je wat systematischer stap voor stap dingen gaat proberen aan de praat te krijgen
Eigen subnet / binnen 1 VLAN:
- Stap 1 Begin bijvoorbeeld eerst eens met statische IP-adressen in de 10-reeks; zorg dat je onderling kunt pingen. werkt het ? -> Stap 2
- Stap 2; krijg je het aan de praat met DHCP? Werkt dat ?

Ik draai nu een 192.168.1.0 reeks in vlan1 van de pix zelf. 10.10.1.0 wil ik hier doorheen laten fietsen eignlijk over hetzelfde touwtje richting de switch, dit zal niet gaan denk ik.

Buiten je subnet:
- Stap 3; kijk of je routering / NAT tussen je 192.168.1.x en 10.0.0.x range aan de praat kunt krijgen
(Let op je VLAN defintie's / ACL's) werkt dat ?
- Stap 4: ga stoeien met NAT translatie m.b.t. je internet connectie
etc.

MOET dit nu dan echt met vlans ? Verklaar je eens nader als je wil.

(boodschap: Bouw het stap voor stap op en probeer niet ineens een niet-werkende VLAN omgeving te troubleshooten)

Mag ik je als tip meegeven dat het geen kwaad kan om naast een " PIX/NAT Google-zoektocht" ook je (nog) eens te verdiepen in subnetting/werking van IP routering in algemeenheid ?
Wellicht vallen, na het lezen van wat white-papers, de puzzelstukjes dan wat sneller op z'n plaats

Happy troubleshooting !

Nu zal dit voorbeel op mij slaan: http://www.cisco.com/en/U...008046f31a.shtml#backinfo

Ik vraag me alleen af of ik gewoon een logical interface aan kan maken op de inside met een IP in het subnet waar ik in zit, en dit IP op de logical gewoon als gateway kan gebruiken.

Het wordt wel duidelijk, ik draai trouwens 6.3(5) en geen 7.0

[Meester_J]

ondersteund die pix geen secondary ip adres?

int eth0/0

ip add 10.0.0.0 255.0.0.0 secondary

[ Voor 6% gewijzigd door Meester_J op 26-12-2006 22:01 ]

[Verwijderd]

Meester_J schreef op dinsdag 26 december 2006 @ 21:59:
ondersteund die pix geen secondary ip adres?

int eth0/0

ip add 10.0.0.0 255.0.0.0 secondary

Volgens mij alleen als logical.

Dus inplaats van seconday, doe je een logical.

[ Voor 9% gewijzigd door Verwijderd op 26-12-2006 22:02 ]

[Meester_J]

en dat lost je probleem niet op?

in combinatie met een extra regel in je nat access-list uiteraard.

dhcp kan je trouwens wel vergeten voor je tweede subnet in deze config.

[Verwijderd]

Meester_J schreef op dinsdag 26 december 2006 @ 22:22:
en dat lost je probleem niet op?

in combinatie met een extra regel in je nat access-list uiteraard.

dhcp kan je trouwens wel vergeten voor je tweede subnet in deze config.

Niet echt.

Wat bedoel jij met een 2e NAT-accesslist voor het subnet ?

Je bedoelt: access-list inside_outbound_nat0_acl ?

DHCP werkt trouwens prima voor extra subnets.

[Verwijderd]

Even een LATE update:

Het pingen van host op het 10.10.10.0 subnet gaat uiteraard wel, zat nog een firewall op de hosts die eth1 niet kende.

Hierna kom ik toch echt op een probleem waar ik, na uren zoeken dus , niet uit kom.

Mijn IP range aan de binnenkant is dus 192.168.10.0, ik kan een aparte VPN naar dit subnet opbouwen en er naar doen wat ik wil, dat werkt.

Nu heb ik ook het 10.10.10.0 subnet waar ik eigenlijk ook een VPN naar op wil bouwen, leek me handiger, en binnen dit subnet hoeft alleen 10.10.10.100 via de VPN benaderd te kunnen worden en moet de 10.10.10.100 naar buiten kunnen communiceren op wat updates van het net op te halen over de 192.168.10.254 gateway.

OK, ik moet hier gaan natten, maar gaat dit helemaal lekker of kan ik er beter een extra nic bij zetten om hier een adres aan te hangen en deze als gatway te gebruiken in plaats van een vlan ?

Als iemand een redelijk voorbeeld kan geven, zou fin zijn, want op de geven Cisco link hierboven staat wat ik wil maar hier natten ze alleen de hosts die binnen hetzelfde subnet als de binnenkant van de PIX liggen.

Dit heb ik dus al wel voor elkaar, het extra subnet nog niet

[Verwijderd]

pix ken ik helaas niet zo goed, maar op de cisco routers werktte het vroeger zo:

2 subnets op dezelfde interface, gewoon de interface 2 ip's geven (in beide subnets 1). Logisch heb je nu al 2 subnets.

Zodra je met vlans gaat werken zal je een switch moeten hebben die vlans ondersteund, je pix zal dan aan je ip pakket een vlan-tag hangen en op basis van de vlan-tag zal het pakketje naar vlan A of vlan B gestuurd worden. Direct deze pakketjes sturen naar gewone hosts/netwerkkaarten zal niet gaan werken...

[recharge]

[quote]Verwijderd schreef op dinsdag 26 december 2006 @ 21:50:
[...]

Bedoel je nu dat ik vlans op de switch zal moeten gebruiken met meerdere nics op de PIX eigenlijk ? Dit zou makkelijker moeten zijn.

Jij bepaalt zelf hoe je e.e.a wil laten connecten. Maar ik zeg dat als je meerdere VLAN's over 1 UTP touwtje van je inside-interface (PIX) naar je switch wil laten lopen ...dat dit dan met een zgn. Trunk poort moet. Standaard is een switchport namelijk maar lid van 1 VLAN. (zie onder ook opmerking over VLAN-tagging)

Klopt, ik was met een vpn aan het connecten, die komt volgens de pix van buitenaf... Trouwens tussen hosts aan de binnenkant ging dit ook met 10.10.1.x op de 2e nic, gateway probleem ?

Opgelost door jezelf

Ik draai nu een 192.168.1.0 reeks in vlan1 van de pix zelf. 10.10.1.0 wil ik hier doorheen laten fietsen eignlijk over hetzelfde touwtje richting de switch, dit zal niet gaan denk ik.

Wat is 10.10.1.10 voor reeks ? van je VPN-client ?
Die kun je wel laten babbelen met hosts op je LAN. (ACL's goed configgen)

MOET dit nu dan echt met vlans ? Verklaar je eens nader als je wil.

Als je meerdere VLAN interfaces hebt gedefinieerd kun je daartussen met ACL's e.e.a manipuleren qua wat wel en niet mag worden uitgewisseld aan dataverkeer.


Maar kom eens met een tekening; dat zorgt voor wat meer duidelijkheid over je situatie.
(fysieke koppelingen tussen pix en switch(es) / IP adressen / ranges)

[Verwijderd]

Ik heb even een tekening gemaakt zoals het eruit ziet in de test.



Ik maak dus een VPN verbinding met de buitenaknt van de PIX (duh) en kan hiermee communiceren naar de 192.168.10.0 adressen met de juiste ACL's

De inside interface zit aangesloten op een unmanaged switch en heeft een IP van 192.168.10.254, dit is de de gateway.

Hetgeen ik eigenlijk wil na veel uitzoeken is dat ik met een extra VPN die ik aanmaak in de 10.10.10.0 range kan communiceren met 10.10.10.200 (in dit geval) op iedere mogelijke manier. De 10.10.10.200 zou eigenlijk ook zijn updates op moeten kunnen halen vanaf het internet indien mogelijk.

Ik moet denk ik dus iets gaan NATTEN van 10.x naar 192.168.x.

Ik vraag me dus ook af asl ik een 192.168.12.x toe zou willen voegen hoe dit dan werkt, ik moet dan dus weer een gateway hebben in die range begrijp ik.

[recharge]

Verwijderd schreef op woensdag 27 december 2006 @ 21:35:
Ik heb even een tekening gemaakt zoals het eruit ziet in de test.

[afbeelding]

Ik maak dus een VPN verbinding met de buitenaknt van de PIX (duh) en kan hiermee communiceren naar de 192.168.10.0 adressen met de juiste ACL's

De inside interface zit aangesloten op een unmanaged switch en heeft een IP van 192.168.10.254, dit is de de gateway.

Hetgeen ik eigenlijk wil na veel uitzoeken is dat ik met een extra VPN die ik aanmaak in de 10.10.10.0 range kan communiceren met 10.10.10.200 (in dit geval) op iedere mogelijke manier. De 10.10.10.200 zou eigenlijk ook zijn updates op moeten kunnen halen vanaf het internet indien mogelijk.

Ik moet denk ik dus iets gaan NATTEN van 10.x naar 192.168.x.

Ik vraag me dus ook af asl ik een 192.168.12.x toe zou willen voegen hoe dit dan werkt, ik moet dan dus weer een gateway hebben in die range begrijp ik.

Waarom gebruik je 2 verschillende ranges ?
Ze zitten beide op dezelfde unmanaged switch aangesloten.
Wat is de toegevoegde waarde ?


Waarom zet je niet gewoon al je servers in hetzelfde subnet en bepaal je op ACL niveau wat je VPN-clients wel en niet mogen naar die servers ?

[ Voor 0% gewijzigd door recharge op 27-12-2006 22:06 . Reden: typo ]

[Verwijderd]

recharge schreef op woensdag 27 december 2006 @ 22:05:
[...]


Waarom gebruik je 2 verschillende ranges ?
Ze zitten beide op dezelfde unmanaged switch aangesloten.
Wat is de toegevoegde waarde ?


Waarom zet je niet gewoon al je servers in hetzelfde subnet en bepaal je op ACL niveau wat je VPN-clients wel en niet mogen naar die servers ?

Goed punt, onderscheid.

Ik wil in een later stadium makkelijker naar een Managed switch toe gaan met verschillende subnets, leek me makkelijk.

Tevens dienen beide subnets echt afgescheiden te zijn, dus vlan zit ik toch wel aan straks.

[recharge]

Verwijderd schreef op woensdag 27 december 2006 @ 23:24:
[...]


Goed punt, onderscheid.

Ik wil in een later stadium makkelijker naar een Managed switch toe gaan met verschillende subnets, leek me makkelijk.

Tevens dienen beide subnets echt afgescheiden te zijn, dus vlan zit ik toch wel aan straks.

Echt afscheiden doe je op dit moment niet. Je unmanaged switch ondersteunt geen VLAN's.

imho ...zou ik voor nu gewoon 1 range blijven hanteren.
Wanneer je t.z.t. een managed switch hebt, kun je tussen je inside interface van je PIX en je switch een trunk opbouwen. Of je zou zelfs gewoon kunnen gaan routeren tussen je PIX en eventuele VLAN interfaces (voorzien van IP-adressen) op je switch (mits je toekomstige switch dit ondersteunt uiteraard).
Op je switch kun je dan bijv VLAN 100 gebruiken voor je 10.- range en VLAN 200 voor je 192.- range etc etc.

[Verwijderd]

Dat wordt dus fijn omprikken van unmanaged naar managed