Complex VPN setup on PIX515

Apr 11, 2006 1 Replies

Been doing a little digging and I have a question I am hoping someone could clear up for me. I have setup a connection to a remote site. I want to only allow a couple of protocols to this site. I envision the following:



access-list apply_to_Nat0 permit ip 10.0.101.0 255.255.255.240 host



10.202.10.91 access-list apply_to_Nat0 permit ip 10.0.98.0 255.255.255.240 host
10.202.10.91 # Don't nat traffic from networks to host 10.202.10.91

access-list apply_to_crypto permit tcp 10.0.101.0 255.255.255.240 host



10.202.10.91 eq ftp access-list apply_to_crypto permit tcp 10.0.101.0 255.255.255.240 host
10.202.10.91 eq https access-list apply_to_crypto permit tcp 10.0.101.0 255.255.255.240 host
10.202.10.91 eq www access-list apply_to_crypto permit tcp 10.0.101.0 255.255.255.240 host
10.202.10.91 eq 81 access-list apply_to_crypto permit tcp 10.0.98.0 255.255.255.240 host
10.202.10.91 eq 81 access-list apply_to_crypto permit tcp 10.0.98.0 255.255.255.240 host
10.202.10.91 eq www access-list apply_to_crypto permit tcp 10.0.98.0 255.255.255.240 host
10.202.10.91 eq https access-list apply_to_crypto permit tcp 10.0.98.0 255.255.255.240 host
10.202.10.91 eq ftp # Allow only www, HTTPS, FTP and port 81 ro 10.202.10.91

nat (inside) 0 access-list apply_to_Nat0 crypto map toMML 600 match address apply_to_crypto



So my basic questions is can I have an access-list applied to Nat 0 which is different from the one I apply to a crypto map?



Thanks,


--AJ



10.202.10.91 eq ftp

If I recall correctly, PIX up to and including 6.1 will syntactically accept port specifications in crypto map access lists, but will grumble about them and ignore them. I believe it was PIX 6.2 that enabled port specifications for this purpose.

Keep in mind that ftp needs a control connection (port 20) and arbitrary ports (1024 upwards) according to the FTP PORT command; the direction that the FTP connections are opened in depend on whether you are using PASV or not, and depend upon which side the data is coming from. As you are controlling the access so narrowly by port number, the dynamically allocated port numbers will not match your apply_to_crypto ACL and so data on them would not be tunneled through the VPN.

cf. the above discussion of the dynamic ftp ports. If the dynamic ports

*are* covered by the nat 0 access-list, then the private IPs are going to be what are in the packets that go out onto the Internet [because the ports are not part of the VPN tunnel] and it would be -rather- unusual for the packets with the internal IPs to get successfully delivered to the other end. If your nat 0 access-list was as narrow as your crypto map, then although the traffic would not go through the VPN, the FTP "fixup" on each end would allow it to get through untunneled.

It is not an outright error to have a nat 0 access-list which is a superset of your crypto map access-list, but you need to consider what you want to happen to the packets that fall inbetween. If you want those packets blocked, then you are likely better off NOT using "sysopt connection permit-ipsec" and instead place appropriate restrictions on the interface acls (access-group ... in interface inside) and then have the crypto map be the more general version; if you configure things that way, then when the PIX adaptive security makes pinholes for ports that would otherwise be denied, the port traffic will travel over the VPN if everything else is right.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required