cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3217
Views
0
Helpful
9
Replies

Routing Issue in PIX 515E

Yuyang Jin
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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

Jorge Rodriguez

View solution in original post

9 Replies 9

JORGE RODRIGUEZ
Level 10
Level 10

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

Jorge Rodriguez

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

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? 

Jorge Rodriguez

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.

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..  .

Jorge Rodriguez

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 ********

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

Jorge Rodriguez

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.

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

Jorge Rodriguez
Getting Started

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: