Can't access internal website over VPN using WAN-accessible FQDN

Hi, Matthew, and welcome to the UTM Community.

Please insert a picture of your NAT rule. Also, tell us if #1 in Rulz gives us any clues.

Cheers - Bob

Thanks for the welcome, Bob!

I've been through the Rulez several times. I could be mistaken, but I'm not seeing any violations.

Let me first reiterate that I have solved this problem to my satisfaction by:

1. Changing the external (WAN Address) port to be consistent with the internal web server port (8088 in this case).
2. Creating a DNS host entry on the UTM that resolves to the internal address of the web server. (Both LAN DHCP and VPN clients are passed the UTM LAN IP as their DNS resolver.)
3. Using either a DNAT rule or a set of WAF rules (my preference) to route requests from the WAN side.

This configuration achieves my goal of allowing a mobile device to access the internal web server using the same URL whether inside the LAN network, connecting via VPN, or from within a trusted remote network.

But what if I didn't have the option of keeping the external port the same as the internal port? That would break things and require the use of two different URLs.

My DNAT rule looks like this:

Using the above rule, if I remove the DNS host entry that resolves the web server domain to the internal IP address, VPN access will break. The Firewall log shows a "Default DROP" from the real WAN IP of the mobile device (which is not part of my Trusted group) to the WAN IP of the UTM, like so:

14:00:40 Default DROP TCP 166.136.184.62:59286 > 71.64.129.162:8088  (IP addresses changed in the interest of privacy)

At the same time, access to the website from with the LAN and from one of the trusted remote networks works fine; the DNAT works as expected.

Once a VPN connection is established, shouldn't the firewall evaluate incoming packets as originating from the *virtual* IP, rather than the real IP? It does this, *if* the destination resolves to a LAN address, but not when it resolves to a WAN address, as above. 

Instead of the "Trusted Networks" group, just use the "trusted remote network."  Remove that network from the group and make a new Full NAT, similar to your DNAT but also changing the source to the IP on the interface attached to PHOBOS.  Or, if you want to keep using split DNS, just do the Full NAT for the VPN Pools.

Cheers - Bob

Like so, right?

Yup, tried this already. Tried checking the box for "Rule applies to IPsec packets", too. The firewall still sees the original remote source IP, not the virtual IP from the VPN pool, and applies the default DROP. I even narrowed the traffic selector down to just the L2TP pool (or the Cisco VPN pool) and the results were the same.

Let me throw another detail into this: I have a 4-port firewall. There is a single WAN port, and the other 3 ports are bridged into the LAN, so that I didn't have to use an extra switch in my little home network. Don't see why that would have an impact, but maybe someone else will. Everything works perfectly, except for this one issue with the VPN. I have tried disabling  IP, ATP, and web filtering. No joy. But thank you for trying!

If your "PHOBOS" object doesn't violate #3 in Rulz, please show the block line from the Firewall log file.  Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.

Cheers - Bob

Apologies for the late reply. I was out of town and computer-free for a few days.

Thanks for the tip on checking the full log. Still, I'm not seeing any new information. Here's the entry in question, when the Full NAT rule is enabled:

2016:03:31-13:28:13 mydevicename ulogd[15815]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:01:5c:67:d2:46" dstmac="00:18:2a:e8:3c:55" srcip="166.172.185.94" dstip="71.91.109.162" proto="6" length="64" tos="0x00" prec="0x00" ttl="50" srcport="49610" dstport="8088" tcpflags="SYN" 

PHOBOS is not bound to any interface, but it does receive a static IP from the DHCP server running on the LAN (bridge) interface.

The srcip is not from a VPN Pool nor is it from one of your LANs. If that IP is one that should be allowed in, you should add it to the group in the DNAT.

Cheers - Bob

The srcip is not from a VPN Pool nor is it from one of your LANs. If that IP is one that should be allowed in, you should add it to the group in the DNAT.

Cheers - Bob

BAlfson said:

The srcip is not from a VPN Pool nor is it from one of your LANs.

Yes, that's what I keep trying to communicate. [:D] The srcip appears to come from the real remote IP and not the virtual IP from the VPN pool.

Ahhh!

It's the client that's not sending the traffic through the tunnel.  Add "External (Address)" to 'Local Networks' in the SSL VPN Proflie.  Any luck with that?

Cheers - Bob

That doesn't work either. But I think I can surmise why:

When there is only one WAN IP, it can't simultaneously function as a VPN termination point *and* the resolved IP for internal services that are accessed via NAT rules (or reverse proxy). Any traffic destined for the VPN termination IP does not go through the tunnel, since the assumption is that this traffic is strictly for tunnel maintenance. I therefore does not appear as coming from a virtual (VPN pool) IP.

To do as I would like to do, I would need to add another WAN IP, and use that for my traffic selector in my NAT rules. Unfortunately, since I'm using DDNS to resolve my ISP-assigned WAN IP, this is not an option for me.

Does that sound right? 

Theoretically, that should work. What do you see in the firewall logs?

Cheers - Bob

Nothing different in the logs.

I don't know why that wouldn't work.  I guess the easiest would be to complete the 'Remote Access >> Advanced' section so that the VPN clients get the local IP of the webserver instead of your public IP.

Cheers - Bob