NAT/routing issue from one subinterface to another

[WStoffel1]

I have a customer that sits behind an ASA on Int g0/1.143 (sec-level set to 100).

I have another customer that sits behind the same firewall on Int g0/1.156 (sec level = 100 as well).

The default gateway for each customer is the ip address on the above interfaces, 192.168.143.254 and 192.168.156.254 respectively.

The customer on 1.156 has a web server that's up and alive on the internet, natted to a public address of 72.46.x.x.

Customers on 192.168.143.0/24 cannot get to the website.  When i tracert from 192.168.143.10 i can see the router that sits on the outside interface of the ASA then it fails, so it's being sent out the default gateway of the ASA.

What am i missing here?

Thanks as always....

[varrao]

Hi,

What you might be missing is a nat command and also the command:

same-security-traffic permit inter-interface

If you can share your configuration or atleast the interface configuration, I can suggest you more specific configuration for it.

Thanks,
Varun Rao
Security Team,
Cisco TAC

[WStoffel1]

Kind of hard to show the whole config, it's enormous, and i have customers behind it.  Same security traffic is enabled inter and intra.

But the two interfaces are:

interface GigabitEthernet0/1.143

vlan 143

nameif Amherst

security-level 100

ip address 192.168.143.254 255.255.255.0

interface GigabitEthernet0/1.156

vlan 156

nameif Franklin

security-level 100

ip address 192.168.156.254 255.255.255.0

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

I thought it was just similar to another issue I had help resolving last week...i thought i just needed a static nat:

static (Amherst,Franklin) 192.168.143.0 192.168.143.0 netmask 255.255.255.0

But that didn't work.

[Jouni Forss]

Hi,

Are you trying to reach the site from behind the ASA (on the LAN) using the public NATed IP of the server?

I guess you are trying to test connections or reach it using DNS name?

Make sure you have a "dns" parameter in the "static" command for server you are trying to reach.

Example might be

static (inside,outside) 1.2.3.4 10.10.10.10 netmask 255.255.255.255 dns

This will make it possible to reach the server using the public DNS name from the local LAN. What the ASA will do with the "dns" parameter is that it will see the DNS query go out and the reply come in. It will then modify the DNS reply sent to the client by changing the resolved IP address to the local LAN address of the server.

Though for this to work you will have to be using public DNS server or the server has to be somewhere behind the ASA so that the clients DNS query will be seen by the ASA. If the DNS server is in the same LAN as the client ASA wont see the DNS query.

You cant simply use the public NAT IP from behind the ASA to connect to the server  OR you would possibly have to make NAT configurations that would also affect your access rules between those interfaces.

I might have understood you incorrectly but it seemed like an issue I just described above.

- Jouni

[WStoffel1]

Are you trying to reach the site from behind the ASA (on the LAN) using the public NATed IP of the server?

     Yes

I guess you are trying to test connections or reach it using DNS name?

     Yes, dns name.  I'm trying to get from one inside interface, to a web page on another inside interface.

This is actually eerily similar to another post I have going currently, but I'm having trouble making the leap on the dns resolution/natting problem.  So please bear with me.

My Amherst subinterface above is a complete /24 lan.  Meaning it's a customer's office Active Directory domain....and the domain controlller, 192.168.143.10, which of course is all of the clients DNS server.  Client dhcp addresses are 192.168.143.100-200.

The web server sits on the Franklin interface, 192.168.156.20 and has a public nat:

static (Franklin,outside) 74.11.x.x 192.168.156.20 netmask 255.255.255.255

What you're saying above is this nat should read:

static (Franklin,outside) 74.11.x.x 192.168.156.20 netmask 255.255.255.255 dns

However, since the dns query would never leave the 192.168.143.0 network, it's not going to work.  Correct?

[Jouni Forss · Accepted solution]

Hi,

When we have run into this problem the most common solution has been to do configuration change on the actual LAN DNS server.

I guess one option is also to do a Static NAT between the 2 LAN interfaces. In other words NAT the Web server LAN address to the public IP address towards the other LAN. In this case you have to take into consideration that all traffic from the LAN initiating the connection have to use the new public Static NAT IP address. It could therefore affect some LAN - to - LAN traffic (not VPN but actual LAN to LAN through the same ASA )

Example command would be (with made up IPs and names)

Static NAT to outside

static (lan1,outside) 1.2.3.4 10.10.10.10 netmask 255.255.255.255 dns

Static NAT between LANs

static (lan1,lan2) 1.2.3.4 10.10.10.10 netmask 255.255.255.255

I'm not sure would a Static Policy NAT be even better. To my understanding it would be done in the following way

access-list WEBSERVER-POLICY-NAT permit tcp host 10.10.10.10 www 10.10.20.0 255.255.255.0

static (lan1,lan2) 1.2.3.4 access-list WEBSERVER-POLICY-NAT

Where:

• 10.10.20.0/24 is the other LAN

I guess this should work too BUT I can't say for sure as I'm just writing this off my head. The above Static Policy NAT should only apply for the web/http traffic with the Web server, other traffic would use the actual IP address of the server when connecting from the other LAN.

I can't test this at the moment with an actual ASA so I can't confirm if the above configuration is possible or if it would work. The first option I mentioned should work but as I said it might cause problems between the LANs if the Web server has some other services towards the other LAN.

- Jouni

[WStoffel1]

While I digest this, and thanks for all your help by the way, I'm wondering if your first thought isn't the right way to go on this:

When we have run into this problem the most common solution has been to do configuration change on the actual LAN DNS server.

what sort of creativity are you thinking there?

I'm thinking you mean an A record for the web server using the private IP, then an access list to allow HTTP from nameif Amherst->nameif Frankin?

[Jouni Forss]

Hi,

I'm not sure how the change is configured as I don't handle any kind of IT in my work or anything related to server other than use them

The basic idea is just to do the same on the actual DNS server that would have been done on the ASA with the "dns" parameter. Basically a separate configuration that would tell any host/client requesting the IP address with DNS query to contact the local IP address and NOT the public IP address.

This would atleast eliminate any need to modify the ASA configurations by doing special rules there. I always aim to keep the firewall NAT configurations simple so they don't come back to haunt me later.

But I guess the DNS configuration on the DNS server might be a same sort of special setup that might cause problem while troubleshooting if the configuration isnt documented well etc.

- Jouni

[WStoffel1]

Gotcha.  I'm a jack of all trades master of none

I might investigate the local dns server a bit more, as I break something there it affects a 20 person office.  I mess up the ASA, dozens of different customers feel the pain.  And apparently no one knows what a lab is so I'm kind of stuck doing this right in production. 

I can add an entry, even as a test a host file entry on a workstation, and a route now that i think about it, pointing to the Franklin web server at 192.168.156.20 instead of the public....and if i lowered the security level on Franklin then i should be able to traverse Amherst to Franklin....off the top of my head, still might need to work that out a little better..thanks though!

[Jouni Forss]

Hi,

I feel your pain I'm kinda cautious testing things on our ASAs or FWSMs (A major screw up or run in with a bug in a software can affect up to 200 separate firewalls, though I guess that would be pretty rare occurence) Usually have an ASA5505 at hand though and some test Security Contexts.

I totally forgot to mention about testing this by changing configuration on the a single clients host file.

The "dns" parameter you can naturally also test (if you see any reason for it) by changing some test computers DNS server to public DNS for the tests.

Please let us know if get this settled and please mark the question answered/rate the answer if you feel its been of help. Always keeps the motivation up for everyone answering on these forums.

- Jouni

[Jouni Forss]

Oh and by the way,

I think most ASAs (atleast models 5510 and above) should have available 2 Security Contexts for your use. So if you want to totally overhaul your ASA setup and get 2 virtual firewalls (one for production and one for tests) if would be possible.

It does naturally take some time/work and changing from single firewall to multiple mode (virtual Security Contexts) will eliminate some features from the ASA depending on your used software. One major example is loosing support for Client VPN. (L2L VPN work only with newest software)

- Jouni

[WStoffel1]

Interesting that you mention that.  It's a 5540 in single context mode, but I've noticed there were two contexts available and never paid much attention to it.  But the ASA has a secondary and since it's single context i just always thought it was Active/Standby.  I didnt set any of this up, i just support it now.  But last night it failed over and now trying to figure out why.   Then i notice it's Active/Active.  But it can't be since Active/Active is only supported in multiple context mode.  So i haven't quite made sense of that.  But then i see the 2 security contexts you mention and it made me laugh.   These forums far outweigh any book i've bought.  The main reason we havent been multiple context is the tunnels, we have several dozen L2L.  But multiple contexts make much more sense for this environment, considering we're only at 8.04, i didn't even know vpn was supported in newer code.  Now completely off topic from where i started, but thanks again for the enlightenment!

[WStoffel1]

Yes thank you, I have a bit of testing to do, fortunately with Thanksgiving i have a few days of downtime to work around.  I'll post back my results, but yes i need to keep people such as yourself motivated, since i often find myself in unchartered waters.  Love the challenge, but to easy to break things!

[n_schloemer]

I would have to agree with JouniForss.  Since the firewall is pushing the web trafic out the external interface and then attempting to hairpin back to the .156 interface, more than likely the ASA is going to natively look at the tcp syn-ack process and deny it.  Do you have any debugs of the session traffic which you could post?  Either way, I would suggest two different options.  First could probably be the easiest for future troubleshooting or maintenance and that would be to add an A record on the local DNS server for the .143 subnet so it resolves to the .156 internal IP address of the web server.  This is going to force the ASA to recognize the locally connected route of .156 as the destination and route the traffic accordingly.  Along with this you will need to add the appropriate ACL's and NAT exempt statement to allow the routing.  Something like this:

access-list AMHERST_ACCESS_IN ext permit tcp 192.168.146.0 255.255.255.0 192.168.156.0 255.255.255.0 eq http

nat (AMHERST,FRANKLIN) source static AMHERST_SUBNET AMHERST_SUBNET destintation static FRANKLIN_SUBNET FRANKLIN_SUBNET

The other option would be to add a class-map which matches the source traffic of Amherst to the destination of the webserver and add the policy-map which will allow tcp-state-bypass.  You could add this rule to the default system service-policy or the interface.  Below I have added a link that speaks about tcp-state-bypass.

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.pdf

[WStoffel1]

quick question, how would you debug the session traffic?