PIX520 Site to Site VPN NAT problem

Unanswered Question
Apr 28th, 2008

I am trying to get a site to site VPN established from a PIX520. There is only one outside interface IP and NAT is setup on the PIX. The NAT works fine for general web/email etc and all inside hosts connect to websites reporting their IP as the outside interfaces IP.

The problem I'm having is that the VPN isn't doing the NAT. The tunnel passes stage 1 but then the inside host that is trying to connect is still connecting using it's own inside IP and not being natted to the outside interfaces ip.

I have been reading various info for about a week and I have even removed all the "nonat" entries on the PIX but it still does not get natted.

Any ideas ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
acomiskey Mon, 04/28/2008 - 05:38

Generally, you do not want traffic natted over a l2l tunnel. But if you do, remove the nat (inside) 0 access-list command. Then you must add the outside interface to the interesting traffic acl.

So instead of...

access-list crypto permit ip

access-list nonat permit ip

nat (inside) 0 access-list nonat

You will have...

access-list crypto permit ip

global (outside) 1 interface

nat (inside) 1 0 0

deanwesthead Mon, 04/28/2008 - 07:58

You are a hero ! Thats got my VPN tunnel up thanks. For some reason the people we are connecting to insist on us coming in with a real routable address.

I still have a problem with this that you may be able to shed some light on.

If I ping a host at the other end of the VPN tunnel, the IPSEC tunnel comes up and they can see encrypted packets coming into them from me and they can also see a response being sent back to me, but I don't get the response back to my host. All I get prom the ping is request timed out.

We have an old Cisco 5500 switch that the host is connected to and this is then connected to the PIX520 firewall. I can ping other sites on the internet without any problems and get the response back. It seems to only be hosts at the other end of the VPN that I lose the packets from.

I'm not sure if it's the 5500 routeing or the PIX routing that is a problem but as I can ping other sites ( eg www.google.co.uk ) I am thinking it is something to do with the VPN setup in the firewall.

Any Ideas ?

acomiskey Mon, 04/28/2008 - 08:19

Is it only ping you are having problems with? Or you cannot communicate at all?

I would check what the other end has defined as interesting traffic. It should be something like...

access-list crypto permit ip

Please rate helpful posts.

deanwesthead Tue, 04/29/2008 - 02:19

No I can't get anything back from the other end. The people at the other end of the tunnel where the server is, say they can see my encrypted packet come into them and they can see their encrypted response packet go out back to me but it just doesn't seem to make it back to my host. If i do a ping from the PIX cli interface i get responses back but from anywhere else it jus times out. I'm looking at the routes setup in both the PIX and the switch behind it.

acomiskey Tue, 04/29/2008 - 06:56

Do you mind posting your pix config? Clean out passwords/public ip's etc.

acomiskey Tue, 04/29/2008 - 08:01

You don't have impulse-cns defined? Maybe you just took that part out.

Anyway, so if you ping something on impulse-cns from the pix command line, it works? And from a client machine inside the pix, it doesnt work? PIX config looks ok.

deanwesthead Tue, 04/29/2008 - 10:24

Yes thats exactly right. Sorry, I probably removed that line from the file before I sent it where impulse-cns is defined.

Thanks forchecking over the config. It's tarting to look like a config problem on the 5500 switch that is on the inside interface of the PIX. The people at the other end of the tunnel say they are replying to the ping etc but it never reaches a workstation on the inside of the pix.

It must be something to do with the routing to/from the VPN because from the workstation on the inside I can ping www.google.co.uk with no problem but just get time outs when I ping a host across the tunnel.

the only thing I dont understand in the PIX config is that the outside interface is for example and when you browse to a site from a host on the inside it reports it's ip as which you would expect, but there is a line in the PIX config that says :

route outside

Wouldn't this route everything out via ? Would that cause a problem if the VPN is created in your previous post using :

access-list crypto permit ip

global (outside) 1 interface

nat (inside) 1 0 0

The VPN using the above cmes up perfectly and i'm told encrypted packets from me hit the other end and they are sending packets back but they get lost along the way.


acomiskey Tue, 04/29/2008 - 13:58

The route outside command is just your default gateway.

Any chance of getting config from remote end?

deanwesthead Wed, 04/30/2008 - 01:19

OK thanks. Will it not cause problems having the default gateway on the PIX not set to it's outside interface IP ?

There is no chance of getting the config from the other end - it connects to a government department !

I'm starting to thing it's an issue with the routing module in the 5500 switch that is on the inside interface and that all the inside hosts connect to.

I can ping the remote hosts across the tunnel from the PIX cli, but if i then go to the 5500 cli and try to ping the same remote host all i get is time out.

What i can't understand is that the 5500 has a really simple config so you would think i could spot the error !

I will keep looking at it.

acomiskey Wed, 04/30/2008 - 05:11

Your default gateway is not the outside interface ip. It is the next hop up from your outside interface.

Want to post the config from the switch?

deanwesthead Wed, 04/30/2008 - 06:50

OK Thanks. I will check that that is the IP of the router to the internet. It must be if the internet is working but I will check it.

I have attached the config of the 5500 switch, both the switch module and the "router" rsm module.

I am trying at the moment to get this working from a workstation on vlan1 ( default vlan ) with an IP of

Thanks for all your help/time with this. These are not bits of kit that I have setup or configured so i'm trying to make sense of someone else's work at the moment.


acomiskey Wed, 04/30/2008 - 08:20


You don't have any inside routes defined on your pix. For example, it needs to know how to get to your inside networks, for example Add this line to your pix...

route inside

...and try again from

deanwesthead Wed, 04/30/2008 - 09:25

Sorry - I probably removed more of the PIX config than I should have when I sent it the first time.

There is an inside route setup. We have 2 sections. one is :

name marshal2

name tsclients

name tswireless

and the second is :

route outside x.x.x.x 1

route inside 1

route inside tsgi 1

route inside mkone 1

route inside psmbilston 1

route inside tsclients 1

route inside 1

so that should cover it but it still does not work.

acomiskey Wed, 04/30/2008 - 09:50

Why is the route to tsclients to Shouldn't it be to

deanwesthead Wed, 04/30/2008 - 11:51

It's OK - this time it's just me. I did the cut and paste above after I had tried changing the default route for tsclients to point to it's vlan IP ( clutching a straws basically ! ). It made no difference and it's now back to .... but still doesn't work.

I can't beleive the trouble this is causing. I thought getting the VPN up was going to be the hard part as routing to everything else is fine. After your first suggested remedy for the VPN brought it up first time I thought I was on a winner ! Here I am 2 days later and I can't get the routing right.

I really appreciate all the help you are giving me. As I said I don't have much experiance with PIX.

acomiskey Wed, 04/30/2008 - 12:02

At this point, I suggest you do some logging on the pix to verify the ping is in fact coming back over the tunnel.

deanwesthead Wed, 04/30/2008 - 13:12

OK Thanks. That will be my task for the morning. I'm still not convinced that the 3rd party at the remote end are sending it back to but I have no way of confirming it except to ask them and they say they are. I will try and setup the logging on the PIX tomorrow and see what that shows.

I will keep you posted.


deanwesthead Fri, 05/02/2008 - 03:08


I don't seem to be getting any usefull info from the PIX logs excpt that when the tunnel is up, if I ping the remote end I can see 1 packet going out and one packet coming in.

Also wouldn't the fact that if I ping from the PIX cli and I get the response back, doesn't that mean it is looking ok via the tunnel ?

Does traffic generated from the PIX cli still go through all the acl's and routing info that is configured in the PIX ?

If so I can't understand why it works from the PIX cli but not from the cli of 5500 on the inside interface ?

I'm really not sure where to go from here.

acomiskey Fri, 05/02/2008 - 06:39

Add this to the pix, then see if an inside client can ping something on the internet.

access-list acl_out permit icmp any any

access-group acl_out in interface outside

deanwesthead Fri, 05/02/2008 - 07:35

I can ping stuff on the internet from a host on the inside now anyway. I can happily ping www.google.com and get the replies back with now problems. it's just hosts over the VPN i can't get too. Pinging www.google.com I get :

U:\>ping www.google.com

Pinging www.l.google.com [] with 32 bytes of data:

Reply from bytes=32 time=23ms TTL=244

Reply from bytes=32 time=21ms TTL=244

Reply from bytes=32 time=21ms TTL=244

Reply from bytes=32 time=26ms TTL=244

Ping statistics for

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 21ms, Maximum = 26ms, Average = 22ms


I have added that line anyway and it still doesn't ping over the VPN.

I have spent a bit more time sanatizing the pix config so it may make a bit more sense to you now ! I have attached the new file.

acomiskey Fri, 05/02/2008 - 09:12

You don't need this...

no access-list outside_cryptomap_20 permit ip required_vpn interface outside


This Discussion