ASA with dual internet - inbound and guest access to web server

Started by Dieselboy, November 04, 2019, 02:59:00 AM

Previous topic - Next topic

Dieselboy

I have a Cisco ASA with 2 internet connections.
I have a web server with NAT  for the primary internet connection. Example:

(inside) 192.168.1.1 -> NAT for internet 1 = (outside1)1.1.1.1


This means I can access 192.168.1.1:80 on 1.1.1.1:80 (remember it's an example...).

For guest users, I have another interface on the firewall called "Guest". I have duplicated the NAT like this:

(inside) 192.168.1.1 -> NAT for guest 1 = (guest) 1.1.1.1

This means that when guest users try to access the URL of the web server, their internet-only connection uses the public DNS server and resolves 1.1.1.1. The url then loads the web server by accessing the 1.1.1.1:80 through the firewall NAT which goes to the 192.168.1.1: server.

So now I want to allow some resilience with DNS round robin and allow internet users to access the web server on either internet connection. So I add a 2nd nat:

(inside)192.168.1.1 -> NAT for internet 2 = (outside2)2.2.2.2

The above is fine. But the problem is with guest. I cannot add the same NAT to the guest interface because I cant have 1 LAN IP NAT to 2 x different IPs.

The issue is when the guest user accesses the URL, it resolves to 1.1.1.1 and 2.2.2.2. If the browser tries 2.2.2.2:80 then the page wont load for over 6 seconds due to the time outs. Then it would try 1.1.1.1:80 and load. 

How have you guys done this kind of thing? Or is there a different alternative that I should be using?

ps. the word in (brackets) is the ASA interface name for the example.

deanwebb

Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Dieselboy

Basically, public internet DNS and Guest DNS are one and the same. Clients on the internet and the guest network get urls resolving to the same 2x public IPs. On the internet it's fine, because of the 2x internet connections and different WAN interfaces on the ASA. But for guest users, I'm unable to NAT the 2nd to the guest interface.

I was looking for an alternative other than DNS re-write. With DNS re-write, the guest clients DNS resolvers wont change but the ASA will replace the public IP with the internal IP in the DNS reply. That way there will be one IP address.  :blank:

Otanx

I would have to poke at it to get it to work, but you should be able to do 2x NATs on the guest interface. You will get a warning, but it should take. Something like

nat (GUEST,OUTSIDE1) source static GUEST_ADDRESSES GUEST_ADDRESSES destination static PUBLIC_WEB1 PUBLIC_WEB_REAL
nat (GUEST,OUTSIDE2) source static GUEST_ADDRESSES GUEST_ADDRESSES destination static PUBLIC_WEB2 PUBLIC_WEB_REAL

With GUEST_ADDRESSES being an object with all your guest network ranges. PUBLIC_WEB1 is 1.1.1.1 and PUBLIC_WEB2 is 2.2.2.2 with PUBLIC_WEB_REAL being 192.168.1.1 I think you get an warning about the NAT only working one way (from guest to web). DNS re-write would work until someone in the future enables DNSSec or DNS over HTTPS, or any of the other encrypted/signed DNS stuff.

-Otanx

deanwebb

How about a DNS round robin with 192.168.1.1 and 192.168.1.2? Both get a 1:1 NAT, but the round robin is now in front of the ASA instead of behind it.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Otanx

That would require standing up DNS servers for the guest network.

-Otanx

deanwebb

Quote from: Otanx on November 13, 2019, 08:46:33 AM
That would require standing up DNS servers for the guest network.

-Otanx


I've had environments where that was done. Kept corporate DNS resources separate from external-facing DNS.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Dieselboy


icecream-guy

Quote from: deanwebb on November 13, 2019, 09:09:17 PM
Quote from: Otanx on November 13, 2019, 08:46:33 AM
That would require standing up DNS servers for the guest network.

-Otanx


I've had environments where that was done. Kept corporate DNS resources separate from external-facing DNS.

which is a good thing,  we internal for internal, external for external,  no running recursive DNS on your external for your internal.  DHS does not like this.  we built up a pair of  recursive DNS server for guest and guest wireless, they get these servers assigned via DHCP. and the servers are in an external VRF outside the border firewall.
:professorcat:

My Moral Fibers have been cut.

deanwebb

Quote from: ristau5741 on November 14, 2019, 06:33:21 AM
Quote from: deanwebb on November 13, 2019, 09:09:17 PM
Quote from: Otanx on November 13, 2019, 08:46:33 AM
That would require standing up DNS servers for the guest network.

-Otanx


I've had environments where that was done. Kept corporate DNS resources separate from external-facing DNS.

which is a good thing,  we internal for internal, external for external,  no running recursive DNS on your external for your internal.  DHS does not like this.  we built up a pair of  recursive DNS server for guest and guest wireless, they get these servers assigned via DHCP. and the servers are in an external VRF outside the border firewall.


In business, this is typically done with a .net for internal networks and a .com for external.

I have one customer that is .com throughout... someone brought in a PC from home named "home" and took down their home.company.com website when the DNS auto-updated the PC as the IP address for the website...
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Dieselboy

LOL  :XD:

But I hadnt thought about that. I'll try and replicate that today (the home.company.com problem). I use j.company.com as our internal domain and our website is at company.com. I have various websites/web apps at something.company.com as well as something.j.company.com for internal-only apps. I'll call a laptop "something" and then plug it into the network.
We have company.net but it's in use for /dev and redirects to the company.com site.

TBH I see "guest" network as the same as someone's home or a random cafe wifi. I dont want to manage any DNS servers there. They can use 1.1.1.1. Admittedly, there is no dns security on the guest LAN.

Otanx

I can't find the document right now, but with DNSSec the best practice is to use a subdomain of your main domain for internal stuff. So public is company.com you would use internal.company.com sub domain to host your internal stuff. Then maybe a ad.internal.company.com for your Windows stuff, dev.internal.company.com for development network, etc. The main reason for this is so you can have a full trust chain from your internal domains all the way to the DNS root that can be validated.

When we had a "hotel" net we treated it the same way. It was for anyone or anything and is not trusted. We ran minimal services. Just a RPi that had tac_plus, and DHCP on it. However it was totally separate as it had a cable modem, and we didn't share an edge firewall like in the NAT issue here.

-Otanx

Dieselboy

Thanks for the info...

NAT = I moved away from dns inspection and used 2 x NAT on the guest interface. I didnt get a warning this time. I was using PAT when I created the first post. Now using 1-1 static NAT. The whole IP is consumed for TCP/80 and TCP/443 but it's fine. No warning and all working :)

DNSSEC = I had to turn it off because it kept breaking randomly. The Firepower inspection is causing it to break and I wasnt able to resolve it via google searches / docs search. I'll come back to it :)

Thanks for your help guys :)