Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 2305 views
  • Users 0 members are here
Options
Suggested
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

snooty
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.
  • 0
    A little update to my issue [:)]

    I found the solution but am still non the wiser as to the reason [:S]
    So any insight would be appreciated.

    I found that my network definition of VPN-0-LAN
    was set as
    Type: Network 
    Interface: External (WAN)
    IP Address: 192.168.0.0
    Netmask:  /16 (255.255.0.0)

    If I change the Interface to: >
    Then all works fine once again and I can disable Auotmatic Firewall Rule in IPSEC
    The Firewall starts to work again.

    What puzzles me is why it worked fine prior to the update.
    And should the Interface be set to > or is that cheating [:$]

    Any insight appreciated

    Thanks
    Peter
  • 0
    Hi Peter,

    normaly every definition should have  as interface (= no interface binding) except the  object. If you have other definitions bound to an interface it's worth a try to delete all bindings and see if thing change in a positive way.

    Regards
    Manfred
  • 0
    #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..

    #1 Don't you mean 'Allow VPN-0-LAN (192.168.0.0/16) -> Any -> Internet'?
    #3 This only serves to eliminate the "60002" default drop lines in the Firewall log.  A packet not specifically allowed by a rule is dropped. 

    Don't you mean "All my remote networks have /24"?

    Like Manfred says, EVERY definition should have 'Interface: >' except Internet.  In V9, that option will only appear on the 'Advanced' tab, and will not so easily lead people to make such errors.

    Cheers - Bob
  • 0
    Hi Bob & Manfred,

    Thank you for your responses.

    #1 Don't you mean 'Allow VPN-0-LAN (192.168.0.0/16) -> Any -> Internet'?

    No, this network does not have general internet access.
    Internet is only used for VPN communication from the remote sites to my location. (CCTV Camera's to my other homes (+File Connection) in case you were wondering!)
    So any device on VPN-0-LAN (192.168.0.0/16) only needs to comunicate to other (192.168.0.0/16) devices.

    This is why I have 
    Internet(Network) --Any--> VPN-0-LAN (192.168.0.0/16)  --> Allow the internal network to communicate with remote VPN devices
    VPN-0-LAN (192.168.0.0/16) --Any --> Internal(Network) --> Allow remote devices to communicate with the internal network

    #3 Deny Any -- Any -- Any
    >>This only serves to eliminate the "60002" default drop lines in the Firewall log. A packet not specifically allowed by a rule is dropped.
    You are of course correct , just a habit of mine [:$]
    I only really need rule #1 and #2

    >>Don't you mean "All my remote networks have /24"?
    Indeed they are all /24, I use the VPN-0-LAN (192.168.0.0/16) on my firewall as a way of catching all of them without having to set a rule for each one.

    Indeed Manfred is correct and I found that changing my interface to > for network definition VPN-0-LAN solved the problem.
    Just not sure why it worked fine prior to the update when it was set to Interface: External (WAN).

    Once again many thanks for all your help.
    Peter
  • 0
    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