This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall Issues Following Upgrade

Hello All,

I have a few Site to Site IPSEC VPN's setup between me and a number of locations.
I was running V8 8.103 and had no problems - everything was working fine.
I decided to use up2date to get to the latest version 8.301 and this updated fine.

After the update the VPN tunnels status shows green and I can ping to devices at remote locations.
However anything more results in a firewall block due to Default Drop Rule.
I did not change any settings between the updates.

My firewall rules are fairly simple
#1 Allow Internet(Network) --Any--> VPN-0-LAN (192.168.0.0/16)
#2 Allow VPN-0-LAN (192.168.0.0/16) --Any --> Internal(Network)
#3 Deny  Any -- Any -- Any

All my remote networks have /16 IP Range e.g 192.168.120.X, 192.168.121.X etc..
My Network is 192.168.150.0/24

I found that I changed rule #3 to Allow Any -- Any -- Any
Then everything works fine - so it is clear that the VPN is fine and it is something to do with the firewall.
Disabling #3 does not do anything as the drop is being done due to the Default Drop Rule.

Through trial and error, I found that now if I enable Automatic Firewall Rules in my IPSEC connection.
Then all works fine.

However this does not explain what I am doing wrong or what has changed [:S]

In a similar way the remote devices use my Gateway for NTP services.
Now they cannot (even with Automatic Firewall Rule checked).
My NTP Services is set to allowed Networks:
# Internal(Network)
# VPN-0-LAN (192.168.0.0/16)

Once again if I add "Any" to the above list then all works fine again.

Have the rules to firewalls changed or has something else gone wrong!

Thanks
Peter


This thread was automatically locked due to age.
Parents
  • Aha, I see - what fun - thanks for the details!

    In a similar situation, I make a Network group containing each of the VPN remote ranges, and then a single rule 'VPN Group -> Any -> VPN Group : Allow'.  The advantage that might have for you is that ISPs screw up all the time and route private IPs, so you would at least not be open to someone on a 192.168 subnet different from yours.  Even if, instead of arriving via a VPN, a packet arrived at the External interface with one of your internal IPs, 'Spoof protection' should block it.  Anyway, just a thought that might enhance security.

    I had only one client on 8.1, and they had no VPNs (only a central ASG and multiple REDs), so I didn't know that binding an interface worked with it.  I've been hammering Astaro about this issue since the option first appeared - at least two years ago.  Not only most newbies, but many folks with a lot of networking knowledge used the binding option in a way the developers of Astaro knew not to.

    Cheers - Bob
Reply
  • Aha, I see - what fun - thanks for the details!

    In a similar situation, I make a Network group containing each of the VPN remote ranges, and then a single rule 'VPN Group -> Any -> VPN Group : Allow'.  The advantage that might have for you is that ISPs screw up all the time and route private IPs, so you would at least not be open to someone on a 192.168 subnet different from yours.  Even if, instead of arriving via a VPN, a packet arrived at the External interface with one of your internal IPs, 'Spoof protection' should block it.  Anyway, just a thought that might enhance security.

    I had only one client on 8.1, and they had no VPNs (only a central ASG and multiple REDs), so I didn't know that binding an interface worked with it.  I've been hammering Astaro about this issue since the option first appeared - at least two years ago.  Not only most newbies, but many folks with a lot of networking knowledge used the binding option in a way the developers of Astaro knew not to.

    Cheers - Bob
Children
No Data