Linux nat issues through cisco asa firewall
hello, my office has a customised web application running on a Linux box. they need access to this application from outside the office and i have a Cisco asa at the perimeter. i did the normal stuff i.e. created a static Nat for the Linux box via the asa. Now this is my issue, the web application has a home page which opens up, after which you need to log on to an account, on clicking the log on button, new page is supposed to open up, this new page is trying to open up using the local ip address of the server and not the translated address, you notice this because the url address in your browser actually changes from the global ip it had before to the local ip of the Linux box. At this point the page cannot open any further since it is an unroutable address and all stops.
I spoke with the application developers and they tell me that the web application will respond back to a request using the ip address of the interface card through which the request arrived which is why the ip address of the browser is changing, thus am beat, is there a way I can get the Cisco asa to work around this?
I spoke with the application developers and they tell me that the web application will respond back to a request using the ip address of the interface card through which the request arrived which is why the ip address of the browser is changing, thus am beat, is there a way I can get the Cisco asa to work around this?
Can you post the config for the static NAT as there are different ways of doing that.
ASKER
static (inside,outside) x.x.x.x y.y.y.y dns tcp 2500 100 udp 2500
It seems to me that problem is with the application which uses local address in first response, not only in packet header but in data field which is not translated by nat
That sounds like a programming error to me, really. Sounds like the onClick of the logon button is trying to launch a new session and that they local IP of the host server is being used. Do I have that right?
No matter what you do, there will be a NAT between the internal host and the external client....unless you run this app on the perimeter itself or, somehow, nonat the public range directly into the host (essentially accomplishing the same thing).
No matter what you do, there will be a NAT between the internal host and the external client....unless you run this app on the perimeter itself or, somehow, nonat the public range directly into the host (essentially accomplishing the same thing).
ASKER
yes your right, the big question is how do i compensate for this on the asa so the issue goes away, am thinking, if i publish the application through microsoft tmg and nat only the tmg via asa, will this solve the issue?i dont have tmg and will want to be sure before buying the software.
>> respond back to a request using the ip address of the interface card through which the request arrived which is why the ip address of the browser is changing
This makes no sense. The Web host could ONLY ever respond back using the same session. It could not open a new session from itself into the requesting client since most clients would be behind their own NAT anyway.
It sounds like the onClick is creating a forward request to its own IP when it should be creating the forwarding request to its own FQDN instead so the client can resolve it himself. Sending back its own non-routable IP will never work.
I don't know to what TMG refers.
But on the ASA side, the best you can do is enable the Global Class Inspections and inspect the protocols you want to watch. The ASA will do rewrites as needed, but I fail to see how this will help here.
This makes no sense. The Web host could ONLY ever respond back using the same session. It could not open a new session from itself into the requesting client since most clients would be behind their own NAT anyway.
It sounds like the onClick is creating a forward request to its own IP when it should be creating the forwarding request to its own FQDN instead so the client can resolve it himself. Sending back its own non-routable IP will never work.
I don't know to what TMG refers.
But on the ASA side, the best you can do is enable the Global Class Inspections and inspect the protocols you want to watch. The ASA will do rewrites as needed, but I fail to see how this will help here.
ASKER
TMG IS MICROSOFT THREAT MANAGEMENT GATEWAY THE REPLACEMENT TO MICROSOFT ISA
have the app developers use the public dns name of the server rather than the interface ip address and it will work fine.
ASKER
hi, could you expand a little more on this, the web server is only for the private use of my office hence we access it using the natted public ip address and not a name.
to clarify, your normally office bound users sometimes try to access this server from the internet? when using it from the office its fine, when using it from the internet they cant login? but you dont have a registered dns name for the site?
it sounds like when you hit the login button, the http code is directing the browser to pop a new window or redirect to a different page. but the code for that page includes the private address of the server, which you see as the url changing to the private address in the browser.
this worrks in the office because the users behind the firewall are able to reach this private address - and the firewall is not involved. but when the user is on the internet, their browser received this redirect to an address that is not routable on the internet, so the session never responds because the browser is unable to contact the server.
test it by going to the home page. hit the login button (and get no response). now edit the url, change just the address part to the public address and hit enter.
e.g if your site public address was 1.2.3.4, which has a private address of 10.10.10.10, you would have a
static (inside, outside) 1.2.3.4 10.10.10.10
config line in the firewall. when you hit login, you might have the url change to https://10.10.10.10/some/url/path/ in the browser. now edit that to change 10.10.10.10 back to 1.2.3.4, so it looks like https://1.2.3.4/some/url/path and the page should now respond.
if this work, then the application code needs to be changed to using 1.2.3.4 (not a robust solution) rather than returning the server interface address, most likely done now through some function call. to make the application more robust, its better to register a dns name for the server, then use that name in the application code. then, when you change isp in the future you wont have to rework the application again.
if theres no java involved, when you hit the login button (now, before making any changes), if you then view the source of the resulting page you should find a reference to the private address hidden in there somewhere. the server code that generates that response is what needs to be changed. maybe you can show the page source to the application guys so they can see what you are talking about.
it sounds like when you hit the login button, the http code is directing the browser to pop a new window or redirect to a different page. but the code for that page includes the private address of the server, which you see as the url changing to the private address in the browser.
this worrks in the office because the users behind the firewall are able to reach this private address - and the firewall is not involved. but when the user is on the internet, their browser received this redirect to an address that is not routable on the internet, so the session never responds because the browser is unable to contact the server.
test it by going to the home page. hit the login button (and get no response). now edit the url, change just the address part to the public address and hit enter.
e.g if your site public address was 1.2.3.4, which has a private address of 10.10.10.10, you would have a
static (inside, outside) 1.2.3.4 10.10.10.10
config line in the firewall. when you hit login, you might have the url change to https://10.10.10.10/some/url/path/ in the browser. now edit that to change 10.10.10.10 back to 1.2.3.4, so it looks like https://1.2.3.4/some/url/path and the page should now respond.
if this work, then the application code needs to be changed to using 1.2.3.4 (not a robust solution) rather than returning the server interface address, most likely done now through some function call. to make the application more robust, its better to register a dns name for the server, then use that name in the application code. then, when you change isp in the future you wont have to rework the application again.
if theres no java involved, when you hit the login button (now, before making any changes), if you then view the source of the resulting page you should find a reference to the private address hidden in there somewhere. the server code that generates that response is what needs to be changed. maybe you can show the page source to the application guys so they can see what you are talking about.
ASKER
hi, just to be a 100%, can i register a dns name for this server in my corporate domain c panel, we have access to that.
if that will result in a public address being registered for the site and being resolvable through the internet - yes.
ASKER
i think i found a way around the problem, the application develpoers were not being usefull so i put in a second network card on the linux server and gave it a public ip address, i also threw in a router as the default gateway of this second card and did a nat zero for this legal ip via the firewall so there is no natting along the way and it seems to work ok now. i will observe it over the next few days.
that would work fine too, but you will need to add static routes for all your internal subnets as the internal network grows, as you cant have 2 default routes (and you need the default route to point to the normal parh towards the internet, which is the original nic).
an alternative solution is to use the nic with puiblic address and configure the asa so that this host exists on a dmz interface, plus remove the first nic. your internal users would then access the server via the public address, and this traffic will route through the asa into the dmz interface. so you only need one nic and everyone accesses the server via the same interface - simpler in the long run?
an alternative solution is to use the nic with puiblic address and configure the asa so that this host exists on a dmz interface, plus remove the first nic. your internal users would then access the server via the public address, and this traffic will route through the asa into the dmz interface. so you only need one nic and everyone accesses the server via the same interface - simpler in the long run?
ASKER
i have ip addresses from only one block and the external interface of the asa is also using an ip address in this block. if i put 2 ip addreses from the same block on the external and dmz interface wont that be overlapping, will the asa accept that config?
it wont, but you can config some rfc1918 (10.x.x.x, 172.16.x.x, 192.168.x.x) address on the dmz interface. config the public address on the host, set the hosts default gateway to the isp router (same as the asa default route address), then create a
static (dmz, outside) public-ip public-ip
and another
static (inside, dmz) public-ip public-ip
plus the appropriate access list entries to allow the required traffic in from the outside interface to the server (the acl entries use the public address of the host). plus, if you have an acl on the inside, add
access-list name permit tcp/udp/ip/? (inside network subnets or "all") host public-ip
and you can make this statement more precise if required, eg adding specific ports if its a tcp or udp permit statement, eg
access-list inside-list-name permit tcp 10.0.0.0 255.0.0.0 host public-ip eq http
access-list outside-list-name permit tcp any host public-ip eq http
static (dmz, outside) public-ip public-ip
and another
static (inside, dmz) public-ip public-ip
plus the appropriate access list entries to allow the required traffic in from the outside interface to the server (the acl entries use the public address of the host). plus, if you have an acl on the inside, add
access-list name permit tcp/udp/ip/? (inside network subnets or "all") host public-ip
and you can make this statement more precise if required, eg adding specific ports if its a tcp or udp permit statement, eg
access-list inside-list-name permit tcp 10.0.0.0 255.0.0.0 host public-ip eq http
access-list outside-list-name permit tcp any host public-ip eq http
ASKER
with the host on a dmz interface (on a cable) with the ip address and default gateway totally diffrent from the asa firewall its plugged in to, will the traffic go out or in, seems to me there will be a routing issue except there is a router somewhere in the dmz as well?
ASKER
coz the asa ip address should be its default gateway, if on 2 seperate networks, needs another layer 3 device to sort out the routing
normally you would be right, but thats the nature of asa static translations. it allows hosts to be effectively forwarded as layer 2 through the firewall, while still performing all the expected security functions for the traffic. this document has some details, although it does not cover the required default gateway requirements:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/cfgnat.html
it also shows the other way to achieve this, that being identity nat.
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/cfgnat.html
it also shows the other way to achieve this, that being identity nat.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
the last 3 para's under usage guidelines here
http://www.cisco.com/en/US/customer/docs/security/asa/asa83/command/reference/s8.html#wp1572088
give some info on what it does.
http://www.cisco.com/en/US/customer/docs/security/asa/asa83/command/reference/s8.html#wp1572088
give some info on what it does.