09-16-2008 05:40 AM - edited 03-11-2019 06:44 AM
I am no security expert but it appears that our pix firewall is blocking traffic from a higher security level interface to the outside interface when there are no access-lists specifically blocking this traffic.
a ping from 217.nn.n.164 to a host on remote subnet 10.0.32.1 accross an IPSEC VPN tunnel which does not terminate on this firewall is unsuccessful. I have determined that the traffic is entering our inside interface and is not reaching the outside interface.
access-list sniffer line 1 extended permit ip host 217.nn.n.164 host 10.0.32.1 log informational interval 300 (hitcnt=123) 0x70a2c4d4
capture sniffercap2 access-list sniffer interface outside
capture sniffercap access-list sniffer interface vlan309-e3
LIV-SVR-01(config)# sh capture sniffercap
10 packets captured
1: 14:25:26.759665 217.nn.n.164 > 10.0.32.1: icmp: echo request
2: 14:25:28.259660 217.nn.n.164 > 10.0.32.1: icmp: echo request
3: 14:25:29.759650 217.nn.n.164 > 10.0.32.1: icmp: echo request
4: 14:25:31.259691 217.nn.n.164 > 10.0.32.1: icmp: echo request
5: 14:25:32.759619 217.nn.n.164 > 10.0.32.1: icmp: echo request
LIV-SVR-01(config)# sh capture sniffercap2
0 packet captured
0 packet shown
I have been looking into this all yesterday and am at a loss as to why this is happening.
The route to the 10.0.32.0 network is in place also and I know it is valid because other routes such as to 10.184.0.0, another customer subnet are routed fine out this interface.
S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside
If anyone can help me out on this issue I would be grateful.
Solved! Go to Solution.
09-17-2008 01:38 AM
Hi,
Firstly, thanks both, for the help so far.
Here are the answers to the questions you have asked.
From your description - VPN traffic should be passin THRU the pix to terminate on the 26xx, is this correct?
The traffic TO BE VPN'd is sent through the PIX to the 2600 which is the router that this customers VPN is configured on. Then on the return path ie. from the customers LAN to us the VPN traffic is decrypted at the 2600 and then forwarded to the PIX. The PIX has the server subnet 217.nn.n.128/26 directly connected on its vlan309-e3 interface.
Maltuna, you are more or less correct, the packet is routed as follows.
host (217.x.x.164) -> in to PIX vlan309-e3 interface (217.x.x.128) -> out of PIX outside interface (217.77.0.?) -> 2600 router(217.77.0.73) -> VPN tunnel -> (10.0.32.1) endpoint
where packet only gets as far as:
host -> ASA -> (dropped), except its a PIX 525 not ASA
The IP network between the 2600 router and the PIX is a single CAT6k switch. I feel that the routing is fine between the PIX and 26k because a traceroute to it from the PIX goes straight to the 2600 before being dropped, because as mentioned before the tunnel is currently down.
LIV-SVR-01# trace 10.0.32.1
Type escape sequence to abort.
Tracing the route to 10.0.32.1
1 217.77.0.73 10 msec 0 msec 0 msec
So it is JUST packets from the server subnet through the PIX to 10.0.32.0 that are dropped, not all packets from the PIX to 10.0.32.0
Anyways, you said that your routing on the ASA is correct:
S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside
This means that 217.77.0.73 is your 26XX router, I would assume.
That is correct. and the PIX does see the correct mac address in arp cache for 217.77.0.73
Also, notice that in the success, in phase 10, it has found a next-hop 217.nn.0.73 (is that actually 217.77.0.73, or a different 2nd octet?), along with a mac address, but in your failure, it doesn't find an adjacency (i.e. no interface with a broadcast domain able to ARP a next hop that leads to the destination network) ?
You are right 217.nn.0.73 = 217.77.0.73,
from the PIX
PIX-LIV-01# sh route | incl 10.0.32.0
S 10.0.32.0 255.255.255.0 [1/0] via 217.77.0.73, outside
The only other thing which confuses me, I noticed that nat-control is on so I believe we need a nat statement for each network that the PIX forwads packets between?
I take this to mean I need the following statement for inbound traffic, which I can see is in the PIX config.
static (vlan309-e3,outside) 217.nn.n.128 217.nn.n.128 netmask 255.255.255.192 where n is the same in both addresses.
but do I also need? This is not in the config.
static (vlan309-e3,outside) 10.0.32.0 10.0.32.0 netmask 255.255.255.0
09-17-2008 01:55 AM
Could it be anything to do with this?
We have an internal network just for transferring data for server backups which uses the 10.0.0.0 address and the servers have dual NICs one with a 10.0.0.0 address and another with a global IP address.
The PIX routes packets to this network from its inside interface.
I can see that on the PIX we have the static nat statement as follows,
static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.255.0.0
To me this would seem to catch the customers 10.0.32.0 subnet but not their 10.183.x.x or 10.184.x.x subnets and as it is for the inside interface (where our backup network is) not the vlan309-e3 interface (where the customers servers are).
Would this cause a conflict for the PIX when looking where to send the packet?
Maybe I'm totally on the wrong track here, but hopefully one of you guys will know :)
thanks
09-17-2008 04:26 AM
Hi, I've figured this out now.
we had the following static NAT which matched all 10.0.x.x from this interface to the inside interface.
static (inside,vlan309-e3) 10.0.0.0 10.0.0.0 netmask 255.255.0.0
I have replaced this with
static (inside,vlan309-e3) 10.0.0.0 10.0.0.0 netmask 255.255.240.0, becuase this easily covers our internal network range
and added
static (outside,vlan309-e3) 10.0.32.0 10.0.32.0 netmask 255.255.252.0
I'm now seeing the traffic making it through to the VPN router.
thanks for the help guys.
09-17-2008 04:38 AM
Chris,
So my post of "Check your NAT statements " helped then?
09-17-2008 05:48 AM
Yes thanks
09-17-2008 05:48 AM
np - glad to help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide