Configuratie PIX 501

[Verwijderd]

Ik heb de volgende configuratie gemaakt naar aanleiding van de example die Cisco geeft op haar eigen website.

---

pix# sh running

: Saved

:

PIX Version 6.3(5)

interface ethernet0 auto

interface ethernet1 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password xxxxxx encrypted

passwd xxxxx encrypted

hostname pix

fixup protocol dns maximum-length 512

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol tftp 69

names

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

pager lines 24

mtu outside 1500

mtu inside 1500

ip address outside xxx.xxx.xxx.50 255.255.255.248

ip address inside 192.168.1.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool pptp-pool 10.1.1.1-10.1.1.50

pdm logging informational 100

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.49 1

timeout xlate 0:05:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout sip-disconnect 0:02:00 sip-invite 0:03:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server TACACS+ max-failed-attempts 3

aaa-server TACACS+ deadtime 10

aaa-server RADIUS protocol radius

aaa-server RADIUS max-failed-attempts 3

aaa-server RADIUS deadtime 10

aaa-server LOCAL protocol local

http server enable

http 192.168.1.0 255.255.255.0 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

sysopt connection permit-pptp

telnet 192.168.1.0 255.255.255.0 inside

telnet timeout 5

ssh 192.168.1.0 255.255.255.0 inside

ssh timeout 5

console timeout 0

vpdn group 1 accept dialin pptp

vpdn group 1 ppp authentication pap

vpdn group 1 ppp authentication chap

vpdn group 1 ppp authentication mschap

vpdn group 1 client configuration address local pptp-pool

vpdn group 1 pptp echo 60

vpdn group 1 client authentication local

vpdn username xxxxxx password *********

vpdn enable outside

dhcpd address 192.168.1.2-192.168.1.33 inside

dhcpd lease 3600

dhcpd ping_timeout 750

dhcpd auto_config outside

dhcpd enable inside

terminal width 80

Cryptochecksum:xxxxxx

: end

---

De clients achter de pix krijgen een dhcp adres uit het 192.168.1.0/24 netwerk en de clients buiten het netwerk die een vpn connectie maken krijgen een adres uit de pool 10.1.1.1-50. De accesslist zorgt ervoor dat ip verkeer mogelijk is van 10.1.1.0/24 naar 192.168.1.0/24.

Echter ik mis iets. Het is gelukt om van buiten het netwerk een vpn connectie te maken naar de pix. Ik krijg netjes een 10.1.1.1 adres. Hoe moet ik echter de clients benaderen die in het 192.168.1.0/24 adres zitten? Mijn computer weet natuurlijk de route niet. Als ik een statische route maak op mijn werkstation dat 192.168.1.0/24 netwerk via 10.1.1.1 moet lopen werkt het niet.

Kan ik de vpn adressen uit de pool niet gewoon adressen uit het 192.168.1.0/24 meegeven en geen acceslist toepassen?

[ Voor 1% gewijzigd door Verwijderd op 12-07-2007 13:54 . Reden: ssh werkt, ca certificate maken ! ]

[Powermage]

Jou PC zal de pix als default router gaan zien wanneer hij naar een 192 adres gaat connecten, en de pix weet de weg wel te vinden.

[Verwijderd]

Ja dat dacht ik dus ook, aangezien "use default gateway on remote network" standaard staat aangevinkt onder windows XP.

Nadat ik vpn connectie heb gemaakt, probeer ik te telnetten naar 192.168.1.1 (=de pix, wat lukt als ik binnen het netwerk zit), maar dit lukt dus niet.

Ik heb ook even geprobeerd met 2 werkstations buiten het netwerk om een vpn connectie te maken en dit lukt op allebei. Ze hebben respectievelijk het adres 10.1.1.1 en 10.1.1.2 gekregen. Elkaar pingen op deze adressen werkt niet.

[paella]

Beide VPN connecties zitten op de outside interface en hebben dus beide seclevel 100. Die mogen standaard niet met elkaar praten. Volgens mij dan.

er is een command, same-security-traffic permit intra-interface

[ Voor 33% gewijzigd door paella op 26-06-2007 12:40 ]

[Verwijderd]

ok, vpn connecties onderling mogen niet met elkaar praten vanwege een bepaalde security level, duidelijk.

Maar waarom kan ik vanaf mijn vpn connectie niet naar mijn inside network (192.168.1.0/24) pingen, connecten etc.

Ik vermoed dat het aan de 2 volgende regels ligt

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
..
nat (inside) 0 access-list 101
..

Alleen zo wordt het voorbeeld ook gegeven op de cisco website (http://cisco.com/en/US/pr...ple09186a0080143a5d.shtml. Zij gebruiken alleen 10.1.1.0/24 als inside network en als "vpn pool" gebruiken ze 192.168.1.1-50, maar dit moet verder niet uitmaken, lijkt me).

Ik zit helaas nu niet op locatie, dus ik kan nu niet experimenteren op de pix. Ik hoop dat iemand zo op het eerste gezicht kan zien, wat ik fout heb in mijn config.

[paella]

Draai je productie? Zoniet, zet eens een icmp debug aan.
Die access-list gebruik je voor je NAT0, niet als "echte" access rule. Zou het kunnen dat je dus geen rule heb dat je van je VPN naar je inside mag? Dat is tenslotten en lager seclevel en mag dus niet.

(ik moet er weer een beetje inkomen )

[ Voor 7% gewijzigd door paella op 26-06-2007 12:50 ]

[Verwijderd]

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

boosdoener? Lijkt er op dat pix niet helemaal goed kan omgaan met de volgorde van natting. Hij wil de vpn pool gelijk natten naar outside adres voordat hij het eerst naar een inside adres heeft genat.

---

ik denk dat ik
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
vervangen moet met
nat (inside) 1 192.168.1.0 255.255.255.0 0 0

Ik moet helemaal inkomen, ik werkte normaal gewoon op ios. pix heeft net iets andere commands ervaar ik.

[ Voor 74% gewijzigd door Verwijderd op 26-06-2007 14:09 ]

[Verwijderd]

Verwijderd schreef op dinsdag 26 juni 2007 @ 13:13:
nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

boosdoener? Lijkt er op dat pix niet helemaal goed kan omgaan met de volgorde van natting. Hij wil de vpn pool gelijk natten naar outside adres voordat hij het eerst naar een inside adres heeft genat.

---

ik denk dat ik
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
vervangen moet met
nat (inside) 1 192.168.1.0 255.255.255.0 0 0

Ik moet helemaal inkomen, ik werkte normaal gewoon op ios. pix heeft net iets andere commands ervaar ik.

Gisteravond op colo geweest. Dit verhielp het probleem. Iedereen thanks.

[Verwijderd]

kan ik mijn 'vpn pool' (10.1.1.1-10.1.1.50) gelijk inside ip addressen meegeven? Nu worden deze eerst genat d.m.v.

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
..
..
nat (inside) 0 access-list 101


ik heb namelijk een sip server in mijn 192.168.1.0/24 netwerk staan en die werkt niet helemaal lekker met NAT.

[Flyduck]

Verwijderd schreef op donderdag 12 juli 2007 @ 12:08:
kan ik mijn 'vpn pool' (10.1.1.1-10.1.1.50) gelijk inside ip addressen meegeven? Nu worden deze eerst genat d.m.v.

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
..
..
nat (inside) 0 access-list 101


ik heb namelijk een sip server in mijn 192.168.1.0/24 netwerk staan en die werkt niet helemaal lekker met NAT.

met de regel "nat (inside) 0 access-list 101" geef je juist op dat er geen NAT plaatsvind, dus beetje vreemde vraag?

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 13-07-2007 14:08 . Reden: even mijn comment buiten beschouwing laten, ben verder aan het inlezen ]

[bazkar]

Inderdaad een NAT 0 commando geen aan dat er geen NAT moet plaatsvinden.

Even ter aanvulling op paella:

Het same-security-traffic permit intra-interface commando werkt pas vanaf PixOS 7.0 en dus NIET op een PIX501 of PIX506, deze gaan niet verder dan PixOS 6.3.