02-17-2009 03:19 AM - edited 03-11-2019 07:51 AM
A client's network has a PIX 515 and an ASA5505 on the internal network. DHCP sets the PIX as the default-gateway for all of the network hosts, bar four. These four machines are configured to use the ASA as their default-gateway - this is a solution for a convoluted setup involving VPNs and static NATing to other private IP addresses...
In short, these four machines are unable to route all non-VPN traffic through the PIX, despite the ASA having the PIX as it's 'gateway of last resort'. Every packet is dropped by the implicit deny rule on the inside interface.
How can I get the packets to passed to the PIX successfully?
Config of the ASA is attached.
Solved! Go to Solution.
02-17-2009 05:31 AM
I think this is because your default gateway is pointing back out the inside interface and you don't have a translation set up for that.
I would try adding the intra-interface command with the following NAT exemption:
access-list nat0 permit ip Net_LAN 255.255.255.0 any
nat (inside) 0 access-list nat0
02-17-2009 04:58 AM
So you're trying to get traffic from these 4 hosts to hit the inside interface of the ASA and be routed back out this interface to the PIX? I believe you need to configure hairpinning on the ASA via the following command:
same-security-traffic permit intra-interface
02-17-2009 05:16 AM
OK. I've tested that and I get the following in the ASA logs:
portmap translation creation failed for tcp src inside:[SrcIP]/[SrcPort] dst inside:[DstIP]/[DstPort]
where the SrcIP is on the LAN and the DstIP is some public IP address.
02-17-2009 05:31 AM
I think this is because your default gateway is pointing back out the inside interface and you don't have a translation set up for that.
I would try adding the intra-interface command with the following NAT exemption:
access-list nat0 permit ip Net_LAN 255.255.255.0 any
nat (inside) 0 access-list nat0
02-17-2009 05:16 AM
Hi,
Generally firewalls doing like routing packets back out the same interface they recieved them on. Is it possible to move this routing decision further down into your network. ie to an internal switch or router?
02-17-2009 05:29 AM
Hello Andrew,
Eddie is right on the spot for intra-interface issue, but this will cause suboptimal routing since the destination gateway (PIX), the redirecting gateway (ASA) and the originator client are connected to same segment. The SYN packet will successfully reach the destination on internet, but when SYN-ACK arrives at PIX, it is going to forward it directly to originator client, while it had to forward to ASA first then ASA to originator, for a successfull 3-way handshake.
In my opinion, best practise here would be configuring your DHCP server to distribute static routes to clients pointing VPN network to ASA interface. You can achieve this using DHCP Scope option 249.
If you say above solution wont work for your scenario, then you have to configure a NAT rule at inside interface in conjunction with permit intra-interface so that source will appear ASA itself instead the actual originator client. Then PIX will forward return traffic to ASA.
Regards
02-17-2009 06:29 AM
DHCP 249 did the trick!
I do wish that I could have moved the routing decision somewhere else, but that was not an option. I'll maybe recommend to the client that they purchase a 3560...
Thanks for the help, folks.
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