Emulating automatic VPN firewall rules

Paul, please show the Edit of the SSL VPN Profile on both sides.

"The remote firewall is another UTM that's running the transparent firewall so all the HTTP traffic ends up coming from the remote firewall's SSL tunnel address - that 10.242.2.x address."

Sorry, I don't understand that.  When you say "transparent," are you referring to Web Filtering?

Cheers - Bob

Yeah, sorry.   Transparent Mode Web Filtering.  

More details...  Three sites - OFFICE, CUST-A, and CUST-B.  UTM9 at each site.  CUST-A and -B are both site-to-site SSL VPN servers allowing access from OFFICE.   

Tunnel settings at one of the CUST sites looks like below.  DugasEnt is my LAN, 192.168.12.0/24.  Internal for this CUST is 10.10.1.0/24.

 Resulting firewall rules on the CUST UTM below.  Note the "containing 10.242.2.2".

Same pics for the OFFICE end of this tunnel.  Note the automatic rule doesn't have the "containing" addition.

Related...  Here at OFFICE, LAN clients use local AD for DNS.  AD forwards to the local UTM to resolve anything other than the local forward and reverse zones.   Local UTM uses Google DNS as it's forwarder and has Request Routing entries pointing back to the local AD for the local zones.  Local UTM has additional DNS Request Routing entries pointing to remote DNS servers at CUST-A for zones there.  

Also related... The local UTM here at OFFICE has Web Protection > Web Filtering enabled in transparent mode.  I have an entry in Web Protection > Filtering Options > Misc > Transparent mode SkipList > Skip Transparent Mode Destination Hosts/Networks for the CUST-A network.  The web proxy doesn't silently intercept web traffic from OFFICE to CUST-A hosts.

All of this is working fine for accessing the CUST-A network. Local LAN clients can resolve hostnames and connect to webapps.  Local LAN clients can explicitly use the local AD, the local UTM, and the remote DNS servers and resolve entries in the remote zones. They all work.

Now, I recently setup the network at CUST-B.  Very similar setup.  UTM at CUST-B is the server for a site-to-site SSL VPN tunnel connecting the local OFFICE subnet to a handful of subnets at CUST-B.  Same settings server side except for the accessible subnets on that end.  DNS setup there is the same as here with AD handling their local zones and forwarding the the UTM.  The UTM there is forwarding to Google and routing requests for the CUST-B zones to their local AD.  The automatic firewall rules for the VPN at CUST-B has the "containing 10.242.2.2" entry with the identical address - that seems problematic.  The local UTM has the same DNS Request Routing entries except they're for the CUST-B zones and point to the CUST-B AD servers.  There's an entry in the web filter configs to skip transparent mode for destinations on the CUST-B subnets.

Attempts to lookup DNS hosts in the CUST-B zones works from a client on the local OFFICE LAN when I point directly to the remote AD servers.  However, pointing to the local UTM at OFFICE doesn't work.  

I've been sniffing traffic on the UTMs.  Watching port 53 on the local LAN interfaces facing the AD servers at CUST-A and CUST-B while a client on OFFICE tries to lookup www.cust-a.lan and www.cust-b.lan, I see requests from 10.242.2.2 to the AD servers and responses back.  Those responses coming back from the CUST-A network are making their way back through DNS to the local LAN client but the ones from CUST-B aren't.   

Is there a problem with having two of these site-to-site SSL tunnels?  Do I need to explicitly set their virtual addresses somewhere?

And you're not seeing any blocks in the Firewall log?

When you toggle the Client side off at B and then re-enable the SSL VPN a minute later, does it still get the same 10.242.2.2 IP?  What if the unit is rebooted?  Grasping at straws here.  I'm a lot more comfortable with IPsec site-to-sites.

Cheers - Bob

And you're not seeing any blocks in the Firewall log?

When you toggle the Client side off at B and then re-enable the SSL VPN a minute later, does it still get the same 10.242.2.2 IP?  What if the unit is rebooted?  Grasping at straws here.  I'm a lot more comfortable with IPsec site-to-sites.

Cheers - Bob

So, I switched the tunnels to IPSEC and no longer have the issue.  Go figure...

... though I can no longer use L2TP/IPSEC for remote-access users.  Is there a solution to that?

Paul, you can select 'Enable probing of preshared keys' on the 'Advanced' tab of 'IPsec'.

I prefer to use X509 certificates: How to create an X509 key based Site-to-Site VPN

Cheers - Bob

So, if I configure the IPSEC Site-to-Site tunnel to use an x509 cert instead of a pre-shared key, it can coexist with L2TP/IPSEC remote access?

Yes, both ways allow co-existence.  I like to turn on PSK probing in every unit I configure.  I'm unaware of any downside.

Cheers - Bob

PS I just saw that I failed to include 'Enable probing of preshared keys' in my post above - fixed now.

Ah! Checking that box worked.  Thanks much.