12-27-2011 04:03 PM
Hi all,
I have a routing problem here with routing in PIX515E version 6.35. I have some Client PCs located in the DMZ interface of the PIX515E, they connect to PIX using Cisco VPN Client (IPSEC VPN), after that these PCs can be routed to access Servers (static route) located behind Internal interfaces of PIX. I have some Servers located remotely having Internet Access, the gateway router remotely connect to PIX Outside Interface (Internet) using IPSEC VPN then routed to inside Interface (static route).
After establishing IPSEC VPN, the Client PCs behind the DMZ interfaces can access Servers located behind Internal Interface of PIX. So do the remote servers. However, the Client PCs cannot access the remote servers.
Just wondering if there is any restriction for the routing in PIX?
Thanks for the answer.
Solved! Go to Solution.
12-29-2011 02:04 PM
Hi
Thanks for posting , sorry for late reply been a bit busy!
I am not to clear about how you are routing your networks , personally I try being more granular in what is routed where when using static routes with large /16s prefixes .
you have l2l vpn for allowing your remote server 172.16.0.199/32 access to inside by your crypto acl as:
access-list Remote_Server permit ip 172.16.0.0 255.255.0.0 host 172.16.0.199
and also you have nat exempt rule as:
nat (inside) 0 access-list nonat
for DMZ resources RA VPN 172.16.45.129 to access far end Server through that L2L VPN from outside interface you would need to allow it in your L2L Tunnel acl in far end as well for the interesting traffic .
Does the far end have access-list for the L2L tunnel is permiting the RA VPN Client Network ID ?
I would also add to your configuration ant exempt rule on dmz interface just as you do with inside interface
nat (dmz) 0 access-list nonat
Let us know how it works out, I will revisit your config and post again a bit later.
Regards
12-27-2011 05:37 PM
Hi,
From what you have discribed is not a routing issue but instead a restriction, please correct me if I missunderstood.
You said your RA VPN clients connect to your PIX vpn gateway to access resources in DMZ and also in inside interface . You also indicated that you have a remote servers on remote sites (outside) that do also connect to your PIX outside via IPsec VPN and also these servers can connect to inside resources...UP to hear we are fine, your RA VPN clients that connect to your DMZ via Ipsec cannot access remote servers that are connected to outside interface of yur PIX via IPsec, this is like hairpining which is a restriction in code 6.3.5 train.
You need a feature known as same-security-traffic permit intra-interface, also known as hairpining , in which traffic can go out on the same interface in came in , usually for IPsec. This feature was introduced in code 7.x , you would simply need code upgrade from 6.3.5 to 7.x or above to take advantage of this feature. My recomendation upgrade your PIX to ASA , PIX is EOL.
http://www.cisco.com/en/US/docs/security/asa/asa70/command/reference/s.html#wp1673966
Regards
12-27-2011 05:48 PM
Hi Jorge,
Many thanks for the quick response. I think your understanding is all correct, I will see how it goes after the firmware upgrade.
But could you explain to me the hairpin here? The Client PCs are connected from DMZ interface while the remote server connected from Outside Interface? They are different Interface. Or are we talking about the IPSEC itself a logical interface?
Cheers
12-27-2011 06:17 PM
Hi Yuyang,
I did not get it right then, I thought your RA VPN were comming from the outside and accessing DMZ, what I said before was if both IPsec connections the RA client and the remote Servers were comming in through your outside interface.
You terminate RA vpn Ipsec in two interfaces, DMZ interface and outside interface? if so it would be a matter of access rules permitting Servers network ID that come from your outside to access resources on your DMZ, never have run into this scenario but that would be a more logical scenario. Does this make sence?
12-27-2011 06:56 PM
Hi Jorge,
Actually, the RA Client behind the DMZ interface is unable to access the server behind the outside interface. I think it doesn't need access rules to make this happen. Please let me know if I make it wrong.
12-28-2011 05:22 AM
Yuyang,
Can you share sanatized config of your pix, you still need to define what is to be accessed in your crypto access list for RA tunnels NAT rules etc.. .
12-28-2011 03:43 PM
Hi Jorge,
Please see the config below;
Servers behind inside interface 172.16.0.0/16
Remote Server 172.16.0.199/32
RA_Client:172.16.45.129-172.16.45.254
dmz: 192.168.0.0/16
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
access-list from-outside remark
access-list from-outside permit icmp any any echo-reply
access-list from-outside remark
access-list nonat permit ip 172.16.0.0 255.255.0.0 host 172.16.0.199
access-list 101 permit ip 172.16.0.0 255.255.0.0 172.16.45.128 255.255.255.128
access-list Remote_Server permit ip 172.16.0.0 255.255.0.0 host 172.16.0.199
ip address outside x.x.x.70 255.255.255.248
ip address inside 172.16.58.20 255.255.255.0
ip address dmz 192.168.68.20 255.255.255.0
ip verify reverse-path interface outside
ip local pool RA_Client_pool 172.16.45.129-172.16.45.254
global (outside) 1 x.x.x.67 netmask 255.255.255.248
global (dmz) 1 192.168.68.129-192.168.68.254 netmask 255.255.255.128
nat (inside) 0 access-list nonat
nat (inside) 1 172.16.0.0 255.255.0.0 0 0
access-group from-outside in interface outside
route outside 0.0.0.0 0.0.0.0 x.x.x.65 1
route outside 172.16.0.199 255.255.255.255 x.x.x.65 1
route inside 172.16.0.0 255.255.0.0 172.16.58.1 1
route dmz 172.16.45.128 255.255.255.128 192.168.68.1 1
route dmz 192.168.0.0 255.255.0.0 192.168.68.1 1
crypto ipsec transform-set 3des-sha esp-3des esp-sha-hmac
crypto dynamic-map map2 40 set transform-set 3des-sha
crypto map IPSEC 40 ipsec-isakmp dynamic map2
crypto map IPSEC 50 ipsec-isakmp
crypto map IPSEC 50 match address Remote_Server
crypto map IPSEC 50 set peer y.y.y.y
crypto map IPSEC 50 set transform-set 3des-sha
crypto map IPSEC 50 set security-association lifetime seconds 900 kilobytes 4608000
crypto map IPSEC client authentication AuthInbound
crypto map IPSEC interface outside
crypto map IPSEC interface dmz
isakmp enable outside
isakmp enable dmz
vpngroup RA_Client address-pool RA_Client_pool
vpngroup RA_Client dns-server 172.16.9.5
vpngroup RA_Client wins-server 172.16.9.5
vpngroup RA_Client split-tunnel 101
vpngroup RA_Client idle-time 1800
vpngroup RA_Client password ********
12-29-2011 02:04 PM
Hi
Thanks for posting , sorry for late reply been a bit busy!
I am not to clear about how you are routing your networks , personally I try being more granular in what is routed where when using static routes with large /16s prefixes .
you have l2l vpn for allowing your remote server 172.16.0.199/32 access to inside by your crypto acl as:
access-list Remote_Server permit ip 172.16.0.0 255.255.0.0 host 172.16.0.199
and also you have nat exempt rule as:
nat (inside) 0 access-list nonat
for DMZ resources RA VPN 172.16.45.129 to access far end Server through that L2L VPN from outside interface you would need to allow it in your L2L Tunnel acl in far end as well for the interesting traffic .
Does the far end have access-list for the L2L tunnel is permiting the RA VPN Client Network ID ?
I would also add to your configuration ant exempt rule on dmz interface just as you do with inside interface
nat (dmz) 0 access-list nonat
Let us know how it works out, I will revisit your config and post again a bit later.
Regards
12-29-2011 02:41 PM
Hi Jorge,
Thanks for the solution. It works after I put nat (dmz) 0 access-list nonat on.
Another question is, if the RA_Client roam out of the office and need to establish VPN from outside interface, will the following things enable it visiting the remote server?
1. nat (outside) 0 access-list nonat
2. upgrade to 7.0
3. same-security-traffic permit intra-interface
Thanks again.
12-30-2011 12:16 PM
Hi Yuyang,
Thanks for posting the update , glad you got it working.
On the other question you have, that is correct, any Ipsec traffic comming IN and leaving OUT the same interface you will nee that feature I told you about , and that is right, you got the requirements in your list.
Best regards
Jorge
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: