DrayTek UK Users' Community Forum

Help, Advice and Solutions from DrayTek Users

Firewall issue - WAN bound TLS passing after block

More
14 Jun 2018 19:26 #7 by x64
Replied by x64 on topic Re: Firewall issue - WAN bound TLS passing after block
In my 2862, at the bottom of the "Firewall" menu, is an item "Diagnose".

In there you can select source/destination IP and ports., protocol, and run a live test of sending a packet.

It then reports pass/fail and the rule that it acted on. I assume your 2860 has a similar page?

I spent a lot of time deciding how best to layout firewall rules,ad the DrayTek is extremely counter intuitive (for example rule set branching, not happening when the rule is actually executed, but continuing to the end of the current page of rules, THEN branching to the indicated ruleset, and the "Block if no further match" setting. In most brands the rules are decisive in the order they are executed - DrayTek is the other way around.

I also did quite a bit of testing, enabling/disabling various test rules to ensure that I understood the logic of the strange beast before settling on my scheme.

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

More
14 Jun 2018 20:07 #8 by gsb1
Replied by gsb1 on topic Re: Firewall issue - WAN bound TLS passing after block

x64 wrote: In my 2862, at the bottom of the "Firewall" menu, is an item "Diagnose".

In there you can select source/destination IP and ports., protocol, and run a live test of sending a packet.

It then reports pass/fail and the rule that it acted on. I assume your 2860 has a similar page?

I spent a lot of time deciding how best to layout firewall rules,ad the DrayTek is extremely counter intuitive (for example rule set branching, not happening when the rule is actually executed, but continuing to the end of the current page of rules, THEN branching to the indicated ruleset, and the "Block if no further match" setting. In most brands the rules are decisive in the order they are executed - DrayTek is the other way around.

I also did quite a bit of testing, enabling/disabling various test rules to ensure that I understood the logic of the strange beast before settling on my scheme.



Using diagnose is interesting, as the behaviour matches exactly what I want to happen, apart from it doesn't!

So source IP my camera, destination IP the gmail smtp server. Port is 587 source and destination (TLS as set on the camera). Checking UDP and TCP, with my rules configured as above, the traffic is blocked. If I add a fourth firewall rule to allow port 587 it passes. Just as I was expecting to have to do. But with the configuration so that diagnose shows port 587 blocked from the camera, if I test SMTP using TLS on port 587 from the camera, the email gets sent successfully! Back to my original confusion as to why this occurs.

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

More
14 Jun 2018 20:34 #9 by x64
Replied by x64 on topic Re: Firewall issue - WAN bound TLS passing after block
:?

OK................ Yep, on the surface of it, that qualifies as barmy.

I presume that you are entering the gmail SMTP server in the camera config? There is no other infrastructure you have inside your network that is doing the relay? That the "Received:" headers in the message headers of the email received outside show the gmail server receiving directly from the camera (it will show the external public natted address, but hopefully the text name of the sending node in that record will identify the camera)

What happens IRL if you add a fourth rule to BLOCK 578/TCP (SMTP will always be TCP - UDP is never used). Does that stop the email? (we are seeing if the fourth rule gets hit by doing this).
You could also put this block rule on other places and see where it has bite.

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

More
14 Jun 2018 21:31 #10 by gsb1
Replied by gsb1 on topic Re: Firewall issue - WAN bound TLS passing after block

x64 wrote: :?

OK................ Yep, on the surface of it, that qualifies as barmy.

I presume that you are entering the gmail SMTP server in the camera config? There is no other infrastructure you have inside your network that is doing the relay? That the "Received:" headers in the message headers of the email received outside show the gmail server receiving directly from the camera (it will show the external public natted address, but hopefully the text name of the sending node in that record will identify the camera)

What happens IRL if you add a fourth rule to BLOCK 578/TCP (SMTP will always be TCP - UDP is never used). Does that stop the email? (we are seeing if the fourth rule gets hit by doing this).
You could also put this block rule on other places and see where it has bite.



I checked the received email headers and they confirmed the email was received by smtp.gmail.com (the smtp specific on the camera). If I add a fourth rule blocking port 578 from the camera IP, the smtp email still works. This is at least consistent with the first firewall rule setting block any if no further match.

For a sanity check, if I revise my firewall rule 1 to Block Immediately, rather than Block if no further match, the SMTP mail is not sent! Phew! I also set the camera smtp address to one of the IPs for smtp.gmail.com to be sure the email is not sent with DNS eliminated.

Next step, put rule 1 back as it was block if no further match. Then with my camera still using the smtp IP address, I disabled my rule 2 (any service to 8.8.8.8). Now the smtp email fails as expected. Progress!

So rule 4 in place, to allow port 587 and smtp works.

Rule 2 revised to allow service type UDP & TCP port 53 and re-enabled. Camera has smtp address set back to smtp.gmail.com instead of the IP. Rule 4 to allow smtp on port 587 disabled. SMTP from the camera should fail. BUT...SMTP from the camera is successful!

I tried setting the camera to non-Google DNS, and same behaviour.

Why is a rule permitting TCP & UDP traffic on port 53 for DNS, allowing SMTP TLS on port 587?!

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

More
15 Jun 2018 06:50 #11 by x64
Replied by x64 on topic Re: Firewall issue - WAN bound TLS passing after block
Going back to a previous helpers reply, re ticking syslog.... I've never used this for debugging f/w rules yet (debugging three other issues with my router has been more then enough time draw for me!). I'd point out that there is also a syslog tickbox next to the items in each firewall rule.... Maybe try that on the weirdly behaving DNS rule?

This is looking more like something for support..... It seems that you can narrow it down to that rule doing something strange. Possibly do a few more test rules first to prove/disprove evaluation paths, to firm up your case.

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