PIX 6.3 Overlapping network config

STEVE FOWLER · ‎12-13-2013

I have a PIX 506 running 6.3 with multiple VPN tunnels. On one we are attempting to nat two network to a single 192.168.30.10 and the other network to 192.168.30.20 as below. The nat is working and the tunnel is sending the traffic to the remote end, we are also recieving something back according to the IPSec SA but the source PC is receiving nothing.

Is my NAT configured correctly?

Do I need to NAT the returning 192.168.17.0/24 traffic back to the real 10.21.96.0 network?

What am I missing?

access-list 199 permit ip host 192.168.30.20 192.168.17.0 255.255.255.0

access-list fcpa_NAT2 permit ip 10.21.96.0 255.255.224.0 192.168.17.0 255.255.255.0

global (outside) 16 192.168.30.20

nat (inside) 16 access-list fcpa_NAT2 0 0

local ident (addr/mask/prot/port): (192.168.30.20/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (192.168.17.0/255.255.255.0/0/0)

current_peer: 207.179.188.20:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 1443, #pkts encrypt: 1443, #pkts digest 1443

#pkts decaps: 1430, #pkts decrypt: 1430, #pkts verify 1430

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 2, #recv errors 0

local crypto endpt.: 216.191.145.2, remote crypto endpt.: 207.179.188.20

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 2a59d3a

inbound esp sas:

spi: 0x827c5c51(2189188177)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 11, crypto map: banctecmap

sa timing: remaining key lifetime (k/sec): (4607838/26451)

IV size: 8 bytes

replay detection support: Y

Jouni Forss · ‎12-13-2013

Hi,

Are you sure that the traffic inbound is not something initated from the remote site? (Even though it could naturally not reach anything since only a Dynamic Policy PAT is facing the remote site)

What are you using to test the connection?

Have you been taking capture on the actual local host and seen that there is no return traffic?

- Jouni

STEVE FOWLER · ‎12-13-2013

Jouni,

Thanks for responding. I'm in contact with the other end and they are saying they see my traffice come into thier firewall as 192.168.30.20 wchich they nat to a 10.X.X.X, they are also seeing the return traffic to me. I see this traffic on the ipsec sa on my end as shown on the original post.

I've set up a capture as below on my end.

PIX515# sh access-l test

access-list test; 5 elements

access-list test line 1 permit ip any host 10.21.99.99 (hitcnt=0)

access-list test line 2 permit ip any 192.168.17.0 255.255.255.0 (hitcnt=14693)

access-list test line 3 permit ip 192.168.17.0 255.255.255.0 any (hitcnt=0)

access-list test line 4 permit ip any host 192.168.30.20 (hitcnt=0)

access-list test line 5 permit ip host 192.168.30.20 any (hitcnt=0)

This is what I capture

-PIX515# sh cap gtest

13 packets captured

15:33:41.696115 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:42.695993 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:43.695963 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:44.696939 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:45.696817 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:46.696802 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:47.696680 10.21.99.99 > 192.168.17.160: icmp: echo request

15:33:48.696588 10.21.99.99 > 192.168.17.160: icmp: echo request

Jouni Forss · ‎12-13-2013

Hi,

Did you have the "fixup protocol icmp" and "fixup protocol icmp error" configured on your PIX?

- Jouni

STEVE FOWLER · ‎12-13-2013

I did not have either. I put fixup protocol icmp error in but the PIX will not take "fixup protocol icmp".

PIX515(config)# fixup protocol icmp

Usage: [no] fixup protocol icmp error

Steve

Jouni Forss · ‎12-13-2013

Hi,

I guess it might have been only a single command in the older software.

From 7.x onwards they have have been separate and used the format "inspect icmp" and "inspect icmp error"

I assume this did not have any affect on the ICMP going through?

- Jouni

STEVE FOWLER · ‎12-13-2013

No, I'm still stuck on this one. I'm not understanding, I see the xlate being done on this end and going through the tunnel, they see it translate it to thier destination and then see the response translating back to our end. I see the decryption on the tunnel to me but from there it's lost. We get no response to the original source pc.

Steve

STEVE FOWLER · ‎12-13-2013

Is there a way to actually capture the traffic returning to us other than what I have already done in my capture?

Jouni Forss · ‎12-13-2013

Hi,

You have the ACL lines for both direction so you should see everything that goes between these networks. You can only really capture the traffic that has already passed the firewall since if you captured the traffic from the WAN interface of the PIX then it would be encrypted.

The capture seems to indicate that the traffic is not getting through the PIX.

I would perhaps consider adding additional NAT IP address on your side of the L2L VPN and configuring Static Policy NAT to this IP address for a single internal host. This should probably tell if the problem is with the current NAT.

But do my understanding your setup should work too.

- Jouni

STEVE FOWLER · ‎12-13-2013

Thank's Jonui,

I really appericiate your help.I'm not sure what you mean though, I found another post you helped on mentioning the static NAT but when I try it I get the following.

PIX515(config)# static (inside,outside) 10.46.0.0 255.255.252.0 access-l fcpa_NAT1

number of maximum connections should lie between 0 and 65535

access-list 199 line 1 permit ip host 192.168.30.10 192.168.17.0 255.255.255.0 (hitcnt=229)

access-list 199 line 2 permit ip host 192.168.30.20 192.168.17.0 255.255.255.0 (hitcnt=291375)

access-list fcpa_NAT1 line 1 permit ip 10.46.0.0 255.255.252.0 192.168.17.0 255.255.255.0 (hitcnt=219)

access-list fcpa_NAT2 line 1 permit ip 10.21.96.0 255.255.224.0 192.168.17.0 255.255.255.0 (hitcnt=291520)

Do I need to remove this first?

nat (inside) 15 access-list fcpa_NAT1 0 0

nat (inside) 16 access-list fcpa_NAT2 0 0

nat (inside) 10 10.46.0.0 255.255.0.0 0 0

PIX515(config)# sh global

global (outside) 10 interface

global (outside) 15 192.168.30.10

global (outside) 16 192.168.30.20

Steve

STEVE FOWLER · ‎12-13-2013

Just to mention the other end of this is a Juniper firewall.

Jouni Forss · ‎12-15-2013

Hi,

Lets say you add a new NAT IP address to the L2L VPN connection then you could do this

access-list 199 permit ip host 192.168.30.30 192.168.17.0 255.255.255.0

access-list fcpa_NAT3 permit ip host 10.21.96.100 192.168.17.0 255.255.255.0

static (inside,outside) 192.168.30.30 access-list fcpa_NAT3

The above would be the correct format. It presumes that you have chosen the 10.21.96.100 as the host to test this L2L VPN connection and the NAT IP address for that host is 192.168.30.30.

- Jouni

STEVE FOWLER · ‎12-16-2013

Hi Jouni,

I'm still stumped, tried the config above and still no luck. It's really strange I can see from the crypto IPSEC sa results below that the packets are returning via the tunnel but the source gets no response. Below is exactly what I did, I had to do it this way because I don't have access to the 10.21.96.0 networks but I do the 10.46.0.0 networks. Also I don't have access to the Juniper on the remote end so I have to use what they have already allowed.

This stayed the same:

access-list 199 permit ip host 192.168.30.10 192.168.17.0 255.255.255.0

access-list 199 permit ip host 192.168.30.20 192.168.17.0 255.255.255.0

I removed the access-list fcpa_NAT1 and the NAT statment (nat (inside) 15 access-list fcpa_NAT1 0 0 )

I added this

access-list fcpa_NAT3 permit ip host 10.46.1.1 192.168.17.0 255.255.255.0

and

static (inside,outside) 192.168.30.10 access-list fcpa_NAT3 0 0

PIng from 10.46.1.1 to 192.168.17.160

xlate showed this

Global 192.168.30.10 Local 10.46.1.1

ACL shows this

access-list fcpa_NAT3 line 1 permit ip host 10.46.1.1 192.168.17.0 255.255.255.0 (hitcnt=30)

sh cry ipsec sa

local ident (addr/mask/prot/port): (192.168.30.10/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (192.168.17.0/255.255.255.0/0/0)

current_peer: 207.179.188.20:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 78, #pkts encrypt: 78, #pkts digest 78

#pkts decaps: 78, #pkts decrypt: 78, #pkts verify 78

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 2, #recv errors 0

local crypto endpt.: 216.191.145.2, remote crypto endpt.: 207.179.188.20

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 2a59ddf

inbound esp sas:

spi: 0x696bb559(1768666457)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 14, crypto map: banctecmap

sa timing: remaining key lifetime (k/sec): (4607994/26016)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x2a59ddf(44408287)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 13, crypto map: banctecmap

sa timing: remaining key lifetime (k/sec): (4607996/26016)

IV size: 8 bytes

replay detection support: Y

Here's the capture ACL I have running and what it captured.

PIX515# sh access-l test

access-list test; 7 elements

access-list test line 1 permit ip any host 10.21.99.99 (hitcnt=0)

access-list test line 2 permit ip any 192.168.17.0 255.255.255.0 (hitcnt=4923)

access-list test line 3 permit ip 192.168.17.0 255.255.255.0 any (hitcnt=0)

access-list test line 4 permit ip any host 192.168.30.20 (hitcnt=0)

access-list test line 5 permit ip host 192.168.30.20 any (hitcnt=0)

access-list test line 6 permit ip 10.10.10.0 255.255.255.0 any (hitcnt=0)

Capture shows this, the 10.21.99.99 is a continious ping still running

11:32:51.724175 10.46.1.1 > 192.168.17.160: icmp: echo request

11:32:52.680659 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:53.680598 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:53.728813 10.46.1.1 > 192.168.17.160: icmp: echo request

11:32:54.680506 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:55.680430 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:55.733452 10.46.1.1 > 192.168.17.160: icmp: echo request

11:32:56.680369 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:57.680445 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:57.738166 10.46.1.1 > 192.168.17.160: icmp: echo request

11:32:58.680277 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:59.680186 10.21.99.99 > 192.168.17.160: icmp: echo request

11:32:59.743903 10.46.1.1 > 192.168.17.160: icmp: echo request

Thanks for you help

Steve

STEVE FOWLER · ‎01-13-2014

Jouni,

Just to update, I never did find a reason as to why this configuration would not work on a PIX 506 running 6.3. However we purchased another ASA running 8.2 and I did the same configuration, same LAN topology and it worked first try. No clue as to why but I do appreciate all your help.

Steve