Access to internal web server from LAN

[Ibraima.ba1]

Hi,

I have a LAN with a very basic setup (one switch and one router) with no local DNS server (I use 8.8.8.8 as server).

I recently started hosting a website so I have 2 NAT rules: 

1. A NAT overload rule allowing my local PCs to access the Internet

2. A static PAT rule allowing access to my internal web server from outside (note: port port 80 redirected to 8888)

Both rules work just fine. My PCs can browse the Internet and my web server is accessible from outside. 

The problem:

When I want to access my web server from local PCs, DNS resolves www.mywebserver.com to my router public IP (which is correct) but I don't get access to the web server.

What I have tried so far:  

I exempted the initial traffic flow from being NATed (1st NAT rule)

Any idea how to set this up  without playing with name resolution?

I have attached a quick diagram for clarity.

Thank you,

IB 

[omz]

Hi

Are you trying to access the webserver via fqdn from pc? And fqdn resolves to public ip?

You can access your webserver via local IP? 

You could add an entry in the hosts file for your webserver to resolve fqdn to local IP or use router dns..

[Ibraima.ba1]

Hi Omz,

Thanks for the reply. 

Yes, I want to be able to access using FQDN from local PCs.

I know it's possible to alter DNS/host files but we'll have to set the port in the URL since the web server does not use standard http port ... 

What I need is something fully transparent for local users.

Appreciated,

IB 

[paul driver · Accepted solution]

Hello

---

@Ibraima.ba1 wrote:

Hi Omz,

Thanks for the reply. 

Yes, I want to be able to access using FQDN from local PCs.

I know it's possible to alter DNS/host files but we'll have to set the port in the URL since the web server does not use standard http port ... 

What I need is something fully transparent for local users.

---

You have two options, 
1) Change your NAT to Domainless-nat configuration ( no inside or outside domains, =  ip nat enable)
2) Nat hairpinning with policy based routing

Example of option 2 - Nat hairpining.
Lan - 192.168.1.0/24
Internal web server - 192.168.1.100

conf t
access-list 100 deny ip 192.168.1.0 0 0.0.0.255 192.168.1.0 0 0.0.0.255
access-list 100 permit ip 192.168.1.0 0.0.0.255 any


ip access-list extended hairpin-nat
permit ip 192.168.0.0 0 0.0.0.255 host 192.168.1.100

interface loopback 100
ip address 169.254.255.1 255.255.255.255
ip nat inside

route-map PBR
set interface loopback 100

int x/x
description wan interface
ip nat outside
no ip redirects
ip policy-route PBR

ip nat inside source list 100 interface <wan interface>
ip nat source static tcp 192.168.1.100 443 interface <wan interface>  443
ip nat inside source list hairpin-nat interface <wan interface>

[Ibraima.ba1]

Hi Paul,
Thanks for your reply.
The Second option seemed weird to me and I could not fully understand it. So I went for the first solution (NVI nat style).
I removed all nat command referencing the "NAT Domain" and added the below commands. 

Everything works perfectly.

ip nat source list INTERNET interface GigabitEthernet0/1 overload
ip nat source static tcp 192.168.0.1 8888 1.1.1.1 80 extendable

interface G0/1
no ip redirects
ip nat enable
!
interface G0/0
no ip redirects
ip nat enable

Thank you,

[paul driver]

Hello

Glad to hear this.

FYI - keep an eye of the cpu utilization on the rtr, It has been noted nvi nat increases the % usage whilst using this feature.

[wis1027]

I'm just curious, what's the role of the PBR and loopback in nat hairpinning

[ChrisUK]

Loopback is as it sounds. You are allowing local clients to loop back into the LAN to access local resources.

Without it you can't use the FQDN or WAN facing IP address to access local services from a local client, unless ofcouse you go the domain-less route as was suggested as another option by Paul.

There is a caveat, if you are using a VPN service then you can access local services by Public IP/FQDN, but this is because your request is routed through the vpn both in both directions. It is actually the vpn making the request to your local services hence its permitted.