SSL VPN connection works WITHOUT corresponding firewall rules

Hi, Jayson, and welcome to the UTM Community!

This is a corporate tool, and not some version simplified for home use.  All traffic not explicitly allowed is dropped, so your firewall rule only eliminates the drop messages one would normally see in the Firewall log file, so I would delete that rule.

WebAdmin is a GUI that manipulates databases of objects and settings.  A single change there can cause the Configuration Daemon to rewrite hundreds of lines of the code used to run the UTM.  Firewall rules created automatically by WebAdmin are considered before any manual rules you create - see #2 in Rulz.

When you enabled your SSL VPN Profile without selecting 'Automatic firewall rules', you only prevented the VPN client from accessing the subnets in 'Local Networks', so you will want to select that to start.  In order to block everything but two public subnets, you must use two NAT rules in order (again, see #2 in Rulz):

1. NoNAT : {Group containing subnets} -> HTTPS -> External (Address)
2. DNAT : Internet -> HTTPS -> External (Address) : to {non-existant IP}

Instead of HTTPS (TCP 443),  I prefer to use UDP 1443 for a faster connection that doesn't conflict with other uses of HTTPS on the UTM.

Cheers - Bob

Hi Bob, Appreciate the reply. I always prefer to define an explicit deny-any rule at the bottom of a firewall ruleset, as opposed to using the implicit deny any, as i want to track hitcounts againt it. In this case i have just ticked the 'log traffic' option on the rule so it does indeed log every packet in the firewall log.

Thankyou for your suggestion about the NoNAT and DNAT in order to achieve filtering on which subnets are allowed to connect to the VPN. I have implemented this and it is working as desired.

Cheers

A logged explicit Deny rule reduces the information in the Firewall log: Packetfilter logfiles on the Sophos UTM.

Cheers - Bob

Hi Bob,

Your original statement was that an explicit deny any rule "eliminates the drop messages one would normally see in the Firewall log file"....i just wanted to point out this is not necessarily correct if you tick the 'log traffic' option on the rule. Whether it reduces the info in the firewall log or not i do not know.

I have read through the link you provided in your previous message and cannot identify where it is stating that an explicit deny any rule will reduce the information in the log file. Can you advise exactly what information is excluded from a firewall log with an explicit rule vs. a firewall log with the implicit deny rule?

I have compared both of these logs below by turning my explicit deny rule off, and cannot see a difference either (I have sanitised the source, destination, and hostname):

2017:07:16-16:44:30 HOSTNAME ulogd[1876]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="ppp0" srcip="1.1.1.1" dstip="2.2.2.2" proto="6" length="52" tos="0x00" prec="0x00" ttl="236" srcport="443" dstport="32985" tcpflags="ACK FIN"

2017:07:16-16:44:39 HOSTNAME ulogd[1876]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="3" initf="ppp0" srcip="1.1.1.1" dstip="2.2.2.2" proto="6" length="52" tos="0x00" prec="0x00" ttl="236" srcport="443" dstport="32985" tcpflags="ACK FIN"

In the link I provided, you see that fwrule="60001" is a drop out of the INPUT chain.  In the case of an ACK FIN, that will always be true.  If this were an incoming SYN packet that you meant to DNAT to an internal device, 60001 would indicate that the destination in your NAT wasn't an "(Address)" object on the External interface.  60002 would indicate a drop out of the FORWARD chain - that the Service was incorrect in the automatic or manual firewall rule.  See #2 in Rulz.

Cheers - Bob