1 of 1 people found this helpful
here are the details of the default firewall classes
The Firewall Class determines the default firewall rules for packets sent or received on a network connection. These default rules can always be overridden using rules defined on the Packet Filtering page. The following describes each firewall class, and the default firewall rules for forwarded packets. Note that some services on the UTM Firewall unit will be accessible even if forwarded packets are dropped by default. For example, VPN services are accessible for any firewall class.
- Trusted local connection. All packets are accepted by default.
- Untrusted Internet connection. All packets are dropped by default.
- Untrusted local connection that provides services accessible from the Internet. Packets from DMZ to Internet connections are accepted, and all other packets are dropped by default. You will normally create Port Forwarding rules to allow packets from Internet to DMZ connections.
- Untrusted local connection. All packets are dropped by default.
For some network connections, the firewall class is fixed at one of the following:
- Remote Access
- Remote access via dial-in. All packets are accepted by default.
- Virtual Private Network connection. All packets are accepted by default.
- A bridge consists of multiple network connections. The firewall class of each individual connection is used to determine the default firewall rules.
- So access from LAN to DMZ is all allowed by default, but access from DMZ to LAN is all denied by default.
- You can customise this with Packet Filter rules
- Hope this helps.
Is there a good document that explains packet filter rules? I need to figure out how to filter SMTP so that it only allows traffic from one internal host to the Internet and it doesn't seem to work.
Also what order are filters applied? Top to bottom or viceversa?
The rules apply top to bottom...so if a match is made, rule below are not applied.
If you create a new packet filter rule and select 'help' you will get an explanation of how to create a rule.
In your case you need a smtp rule that has type FORWARD and action DROP on SMTP.
Then a rule above it which specifies the source address of you internal mail server, type FORWARD and action ACCEPT on SMTP.
If you have further issues creating the rules, Technical Support can assist.
1 of 1 people found this helpful
Additional debug steps you could consider to see if your rules are doing what you want:
- look at the hit-counters in 4.0 packet-filter to see if your rules are being triggered
- enable a log message with your smtp rules, then look at syslog (Diagnostics) to see what is happening
- turn on connection tracking logging (Connection Tracking -> log beginning/end of connection).
Hit counters are fine if you don't have much happening, so then your test connections will be the only ones, and seeing why the hits are happening is easy.
If you are busy, then logging is better, because it gives you more detail on what got blocked/allowed and why, so how busy you are matters less. Of course, if you have a busy site another question you should ask yourself is whether it is wise to put rules into it before you know whether they will work or not - ideally you would test things like that on a test-rig you have set up with a 'spare' UTM Firewall - then that may not be a luxury available to you.
A trick to consider here is a rule that does nothing other than log that it was run. For example, say you think your SMTP-allow-my-one-host-that-is-special rule is just not getting triggered. Perhaps a more generic rule above in the list is killing your smtp - so how do you find it? Well, you could turn logging on for each of the rules above. Another way to deal with it is to create a 'Just log stuff' rule. It matches all packets (any, any etc. - leave it at defaults) - but you make the action 'NONE', turn its logging on though, and hey-presto you have a rule that you can move up/down the list-of-firewall-rules and it'll tell you how far which packets are making it down the list without actually impacting what is really happening. That should let you narrow in on where unexpected things are happening more easily than having to turn on logging everywhere.
Firewall rule logging has its limits though, so if you really need to see the world, consider connection tracking logging as well. It will create a lot of data in syslog, so probably something to use with remote-syslog enabled so you can look at it in peace and quiet 'off-system'.
What it allows you to do though is to see where a connection came from, where it went to what port in/out etc. combine that with the log-output of when firewall rules you care about trigger, you have a fair chance of getting your head around what is going on.
Another thing to worry about is how to actually create tests traffic. telnet is the first one to consider. A often forgotten feature of even the default windows telnet client is that you can nominate the target port of where you want telnet to go to. So
telnet somewhere.com 1234
will try to connect to port 1234 on host somewhere.com - instead of the usually telnet port (23).
To create some fake smtp traffic then, you don't need to create lots of e-mail, you just
telnet somehost.com 25
Hit enter a couple of times and the other end should give you a friendly text message about how it speaks ESMTP and if you want you can even get it to spit out instructions on how to construct email messages right there from the telnet prompt. But I digress.
telnet has its limits though, so if you need a more sophisticated tool, get yourself netcat - 'nc'. nc can generate UDP as well as TCP traffic, and does not spit out all the pesky telnet initialization traffic. Bit harder to drive though - use 'nc -?' to get some help - but probably just google a manual for it. Its on most UTM firewall devices - so if you have a spare one of those to act as your test-traffic generator, just ssh to your UTM firewall and off you go. Alternatively its downloadable to linux and windows machines. Cygwin is a good option for windows machines as it has a large set of these sort of networking tools to choose from.
UTM Firewalls also include a bunch of other interesting tools you may care about for the purposes of network testing and diagnostics. hping, nmap, tracepath are probably the most useful. Yes, these tools can also be used for evil - it is the way of the world - so be responsible and play nice...
So now you should be able to easily create some test-traffic, figure out what is happening inside the firewall and adjust the rules to suit.
And I should probably put this into a document and call it a firewall trouble shooting guide...
Thanks all for fantastic help! I look forward to one day contributing more than just questions!!!