ASA 5510 subinterfaces+NAT nightmare

[Leader1980]

Hi guys,

We have an ASA 5510 firewall and in our DMZ we have a server listening on port 443. For this server, we already have a public IP address on the ISP' router. All the traffic to this IP address on port 443 is natted to the ASA's outside interface on port 443.  So far, everything is working fine.

We'd like to add another server listening on this same port (443). To do so, we have obtained from our ISP a second public IP address for the second server. As the two servers must be listening on the same port, we have configured a subinterface on the outside interface of the firewall and the ISP has done so as well. We can ping each other on this VLAN, so there is no connectivity issue between us. The ISP's router is natting (and patting) the traffic on the second public IP address to the IP address on the subinterface. We have added an access rule to allow incoming traffic on this subinterface and  a NAT rule to send this traffic to the server in the DMZ on port 443.

But despite the access rule, https traffic on the subinterface is being denied by the implicit rule on this interface as shown in the logs below

Why is the explicit rule on the interface is not being applied? I'm hopeless, I need your help

[Peter Koltl]

Actually, this is my assumption as I haven't encountered a similar setup yet. However, ASA 8.3 documentation states that

"ASA uses the NAT configuration to determine the egress interface. (8.3(1) through 8.4(1)) "

So the interface the translated packet will use to leave the firewall  will be determined by your NAT rule destination interface, and NOT THE ROUTING TABLE.

But the 8.2 docs don't mention this topic, the ASA  may use a similar method. This is what may be saving you even with this setup and cause things to work. You will need extreme caution with the route-lookup keyword when you switch to a newer software version. I would still suggest migrating to the simple setup.

[Leader1980]

Hi Peter,

Thank you for your post. In fact, it was the solution. The outgoing traffic is routed according to the routing table. The ISP router is the default gateway for all the outgoing routes. So, if the traffic is for Host_SFTP or Host_Spamfilter, it's routed back according to the route configured for the appropriate interface, namely Outside for Host_SFTP and Host_Spamfilter. On the Outside interface, there's a default route with outgoing interface Outside and next hop 192.168.0.3 (the ISP's router side of the physical link). And for Host_E2CWeb, on the Outside_3, there's a default route with next hop 192.168.2.1, the ISP's router side of the subinterface. Everything is working so I think this is a possible correct design. Maybe there are others but this one is working fine. The goal by configuring subinterfaces was to separate different traffics on different VLANs. I  went even further by configuring subinterfaces for traffic bound to Host_SFTP and Host_Spamfilter. I can access open services on those servers from the inside and from  the outside and no others services.

Thank you to all of you for your contributions, you are just wonderful!

[Peter Koltl]

OK, I'm glad that it works but don't think that either default route belong to Host_Spamfilter or Host_E2CWeb. Just copy here your default routes: they contain next hop and interface but no referrals to inside zones or servers. Routes are for packets and they don't contain server-based dependencies. ASA routing engine does NOT match the reply packets to leave the box on the same outside interface where the requests came. It is simply destination-based. That is, an outbound request packet  (outgoing HTTP request from your server or desktop) may have problems on which route to choose. I still assume the undocumented NAT preference over routing table lets the outgoing reply packets to find their way which I regard as sort of luck.

[Leader1980]

There's no reference to inside zones. What I meant is that each service has a dedicated outside subinterface for the incoming traffic and the outgoing traffic refers to the subinterface as the egress interface and the ISP's router subinterface as the next hop. There is no matter of luck, because if it just doesn't work if I don't correctly configure default routes per subinterfaces. Subinterfaces are on different VLANs so the don't "see" each others. I don't see another way to configure default routes, apart from doing it by subinterface