Solved: Routing through ASA and PIX

clark-computers · ‎02-17-2009

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.

eddie.mitchell · ‎02-17-2009

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

View solution in original post

eddie.mitchell · ‎02-17-2009

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

clark-computers · ‎02-17-2009

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.

eddie.mitchell · ‎02-17-2009

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

JamesLuther · ‎02-17-2009

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?

husycisco · ‎02-17-2009

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

clark-computers · ‎02-17-2009

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.