DrayTek UK Users' Community Forum

Help, Advice and Solutions from DrayTek Users

Inbound firewall rules for routed public subnet

  • x64
  • Topic Author
  • Offline
  • Junior Member
  • Junior Member
More
21 Jun 2018 15:56 #1 by x64
I am having difficulty controlling traffic from the internet into a non-NAT subnet (using the "Dedicated LAN interface" method) on my 2862ac. ( see https://www.draytek.co.uk/indes.php?option=com_content&view=article&id=443 ) Firmware is 3.8.9.1_BT

I have a /29 public allocation (call it x.x.x.144/29). I've got that set up on my WAN interface (the ISP assigns .150 from the /29 as the external IP), and also configured the /29 up on "LAN8" (bound to VLAN7, which contains a physical port). I have a laptop cabled to that port that I've configured as .146. I also have ordinary NATted devices on LAN1 (they work fine).

Outbound Internet access from the laptop on the public subnet works fine (and appears to be controllable through 'Lan to Wan' firewall rules). However I'm having problems getting INBOUND traffic for the public IPs on the public subnet to trigger firewall rules. For example (for testing), allowing RDP to hit the laptop on .146.

I have the "Block routing connections initiated from WAN" unticked for IPv4. However I DO have the "Default" firewall rule set to "Block" (and I'd rather keep it that way!). As such, in order to allow the test RDP traffic to the laptop, I was expecting only to need to write a firewall rule to allow traffic from the Internet to .146 for 3389/tcp.

I wrote a rule, "WAN to LAN, 'Any IP' to x.x.x.146(specified as an IP address inside the rule), Protocol TCP, Src port 'any' to dest port 3389(later relaxed to any), Pass immediately" and put it right at the top of my "Data Filter" ruleset. However that rule would not trigger.

In Firewall/Diagnose, it predicts that the Default rule would indeed block. Logging real traffic into syslog also shows the inbound connections being blocked by "R=13:1" (which would appear to be the code for the block though the default rule).

The syslog also confirms the direction of the packet (Wan to LAN) which matches my rule, source and destination IP addresses and ports (which also all match my rule).

Reversing the rule to block 'Lan to Wan, .146 to any' blocks outbound traffic from the laptop, disabling that rule allows it again. Additionally, I did briefly set the default rule filter action to 'Allow" and indeed the inbound traffic was allowed.

At the moment, the only effect of the firewall on the public LAN inbound traffic appears to be the Default rule.

Any idea what is going on here, and how to write a selective 'Allow' rule for inbound traffic to the public IPs?

Please Log in or Create an account to join the conversation.

More
25 Jul 2018 12:59 #2 by teasdale
Hi,

Just seen your post. I'm having the same issue after an update to 3.8.9.1_BT. It all worked fine before, but now all the firewall rules are ignored after the update. I've raised a support ticket, but waiting to here their response. Did you get this resolved?

Jim

Please Log in or Create an account to join the conversation.

  • x64
  • Topic Author
  • Offline
  • Junior Member
  • Junior Member
More
25 Jul 2018 19:38 #3 by x64
I've not yet got anywhere meaningful with this, in fact I ended up slipping deeper down the rabbit hole.....

I suspect that my issues are related to a another issue that I posted about here a few days later..... See ( https://forum.draytek.co.uk/viewtopic.php?f=14&t=22441 ). The issue is wider than I posted about. In fact the external IP addresses of loopback connections seemed unpredictable where straight outbound connections come from the default external IP even when aliases exist. I've seen some really wacky packet traces in my tests, particularly in my DMZ subnet.

I've added the problems from my other topic onto a support call that I had about other issues. The only advice so far seemed to contradict Admin3's info about the change in behaviour of multi-nat, and suggested me using Policy Based Routing to force outbound IP addresses. I think I believe Admin3 more.

I'm encircled by the Ride-London cycle event this weekend, so I'll either be doing further testing on this or rebuilding Hyper-V hosts on a corporate network - Oh joy!

Can I ask how much you can relate to the configurations that I described, and which earlier firmware versions that worked you are referring to? Not that I intend to downgrade, but knowing that it HAS worked fairly recently gives me a bit of comfort that it's not a practically insoluble architectural issue within the OS.

Please Log in or Create an account to join the conversation.

More
25 Jul 2018 21:37 #4 by teasdale
Hi X64,

Thanks for your response. I got my 2860 about a year ago and have pretty much updated to the latest firmware as and when it's been made available. My configuration up until recently has been a NAT with a routed IP range. This has been working well for over 10 years, initially with an Vigor 2820) and more recently a Vigor 2860. I've recently split my LAN into 3 separate IPv4 VLANS and added also added IPv6 to the VLANS to make each of the 3 IPV6 VLANS internet routable. I don't have a DMZ.

With the old firmware I was able to block all incoming traffic to the routed range, but allow various ports under my control to be open (mostly HTTP/S and ICMP). I normally put a deny rule at the bottom of the firewall list to deny all inbound traffic then individual rules to open up the ports/ICMP i need. When the Admin HTTP WAN exploit became known and fixed with firmware 3.8.8, I updated within a couple of days of it being made available (18 May). I then updated to 3.8.9.1 to resolve a VPN issue.

I did an NMAP scan outside my own network just randomly to check everything was working as it should and noticed that one of my routed IPs (there was only 1 up at the time) as showing all open ports as if the firewall was not there. When I got back inside my lan, I wiped the router back to a basic NAT/Routed LAN without IPv6 or VLANS and it showed the same issue.

Given the exploit that is present pre 3.8.8, this limits the firmware options to ether 3.8.8 or 3.9.1. I've not had chance to roll back to to 3.8.8 to test the firewall config to see if this version also exhibits the same issue, but I have noticed in the release notes for 3.9.0 (unreleased) that there were some major changes in the firewall config sections so wonder if they broke something and haven't tested it with a routed IP range.

Interestingly, using the new firewall tester built into the router shows the real world behaviour that the the simulated traffic is only being satisfied by the new 'default rule' and not any of my rules I've put in. I've also noted that setting the 'default rule' to block, stops all traffic in and out from going. But writing my own rule to allow traffic out of the routed range is being ignored.

Hope that helps.

Please Log in or Create an account to join the conversation.

  • x64
  • Topic Author
  • Offline
  • Junior Member
  • Junior Member
More
25 Jul 2018 21:51 #5 by x64

teasdale wrote: Hi X64,

Thanks for your response. I got my 2860 about a year ago and have pretty much updated to the latest firmware as and when it's been made available. My configuration up until recently has been a NAT with a routed IP range. This has been working well for over 10 years, initially with an Vigor 2820) and more recently a Vigor 2860. I've recently split my LAN into 3 separate IPv4 VLANS and added also added IPv6 to the VLANS to make each of the 3 IPV6 VLANS internet routable. I don't have a DMZ.

With the old firmware I was able to block all incoming traffic to the routed range, but allow various ports under my control to be open (mostly HTTP/S and ICMP). I normally put a deny rule at the bottom of the firewall list to deny all inbound traffic then individual rules to open up the ports/ICMP i need. When the Admin HTTP WAN exploit became known and fixed with firmware 3.8.8, I updated within a couple of days of it being made available (18 May). I then updated to 3.8.9.1 to resolve a VPN issue.

I did an NMAP scan outside my own network just randomly to check everything was working as it should and noticed that one of my routed IPs (there was only 1 up at the time) as showing all open ports as if the firewall was not there. When I got back inside my lan, I wiped the router back to a basic NAT/Routed LAN without IPv6 or VLANS and it showed the same issue.

Given the exploit that is present pre 3.8.8, this limits the firmware options to ether 3.8.8 or 3.9.1. I've not had chance to roll back to to 3.8.8 to test the firewall config to see if this version also exhibits the same issue, but I have noticed in the release notes for 3.9.0 (unreleased) that there were some major changes in the firewall config sections so wonder if they broke something and haven't tested it with a routed IP range.

Interestingly, using the new firewall tester built into the router shows the real world behaviour that the the simulated traffic is only being satisfied by the new 'default rule' and not any of my rules I've put in. I've also noted that setting the 'default rule' to block, stops all traffic in and out from going. But writing my own rule to allow traffic out of the routed range is being ignored.

Hope that helps.



3.9.0? or 3.8.9(.0)? (the unreleased in UK predecessor to 3.8.9.1. I've not seen preliminary release notes for 3.9.0 yet..

Please Log in or Create an account to join the conversation.

More
26 Jul 2018 06:38 #6 by teasdale
Sorry, typo. 3.8.9.0 (the unreleased one).

Please Log in or Create an account to join the conversation.