Firewall rule tutorial example 2:

Opening an incoming port

:!: This description is addressed to advanced users only.
Incorrect editing of the firewall rules may cause security risks!

Say you want to open TCP port 5032 on your firewall and forward all data coming to it to your PC (192.168.0.31).

Path through firewall. See steps below.

1. The port should be opened for incoming packets from the outside (Internet). Thus the first rule we need to enter is into the incoming super rules of the outside interface. Actually, that ruleset already contains the line:

(daddr == 50.11.69.17/32) accept

meaning “accept everything coming to your global IP address (50.11.69.17)”. That includes port 5032 too. Thus the data will pass through the outside incoming super rules.

2. The next stop for the packet will be the incoming user rules of the outside interface. Here we do not have any rule allowing TCP port 5032 through, thus we need to add one:

dport == 5032 && proto == tcp modify static daddr 192.168.0.31

This needs some explanation.

Why not just a simple accept rule? Because if you simply accept that packet, the router in your SafeGate would not know to what interface to send the packet. It would end up at your global IP address = that's your Internet Gate! But you want to send the packet to your PC, connected to ET1 instead!

The modify static rule creates a flow that will modify the packet: the destination address that was your global IP address 50.11.69.17 (that is how the packet have found you through the Internet) is modified to 192.168.0.31, that is the new end address the packet should go to: your PC. This is how Internet Gate achieves NAT! Now the router will know that this packet should be sent to ET1, the interface that is on the 192.168.0.x subnet.

The modify static rule does even more: it also tells the firewall to stateful inspect all packets that will go through this flow. Also it creates a return flow on the outgoing half of the outside interface. The return flow is the mirror image of the incoming flow: it allows data to be sent out on port 5032 to the Internet, modifying the source address of the packets from 192.168.0.31 back to 50.11.69.17. This is how Internet Gate hides your local IP addresses.

3. Now the router sends the packet to ET1, as the packet destination IP address is 192.168.0.31 (after the modification), and it is ET1 that handles the 192.168.0.x subnet.

4. The next stop for the packet will be the outgoing user rules of the ET1 (inside) interface. Actually, that ruleset already contains the line:

proto != noproto accept

simply meaning “accept everything”. Thus the data will pass through the inside outgoing user rules.

5. The next stop for the packet will be the outgoing super rules of the ET1 (inside) interface. That ruleset too contains the “accept everything” rule proto != noproto accept, thus allowing the packet through.

6. Now the packet will be sent out on the ET1 interface, and reach your PC at 192.168.0.31! If the PC answers (and on TCP connections they do always answer), the answer needs to be able to get out through the firewall again! Let's open the outgoing path too:

7. Your PC sends its answer from its port 5032, back to the IP address on the Internet the data come from. Thus the return packet will have source port 5032 and source address 192.168.0.31. Your PC knows that there is a default gateway on its subnet at 192.168.0.1 thus it sends it there.

8. It is connector ET1 of your Internet Gate that is at 192.168.0.1. The packet is received and compared to the inside incoming super rules. That ruleset contains the line:

saddr == 192.168.0.1/24 accept

meaning “accept everything coming from the 192.168.0.x subnet” (notice the IP mask). Thus the packet is allowed through.

9. The next stop for the packet will be the incoming user rules of the ET1 (inside) interface. Here we do not have any rule allowing TCP port 5032 through, thus we need to add one:

saddr == 192.168.0.31 && sport == 5032 && proto == tcp accept

meaning “accept TCP packets coming from port 5032 of PC 192.168.0.31”.

10. Now the packet is sent to the router. The packet has a destination IP address pointing to somewhere on the Internet. As that address is not on any of the inside subnets of the Internet Gate, the router will send it to its default gateway, the one you have received from your operator. That gateway is accessed through the outside (WAN) interface, thus the packet is sent to that interface.

11. Thus the next stop for the packet is the outgoing side of the outside interface. But it is not the user rules there, as there is a matching flow.

This needs some explanation.

In step 2 above we have added a modify static rule that created two flows: one that inspected and modified the incoming data on this interface, and a return flow with the reverse. The return flow is set to match data coming in the reverse direction on the data path, thus coming on TCP port 5032 from PC 192.168.0.31. Our return packet matches that description exactly.

As there is already a matching flow, the outgoing user rules of the outside interface are bypassed entirely! The flow instead takes the packet to the modifier that modifies the source address of the packet back from 192.168.0.31 to your global IP address 50.11.69.17. This is how Internet Gate hides your local IP addresses.

Then the flow takes the packet to the stateful inspector making sure the packet follows the TCP rules. If the packet violates any of the TCP rules, it will be stopped by the stateful inspection, but all well-behaved packets will be let through.

12. The last stop for the packet through the firewall is the outgoing super rules of the outside interface. This ruleset has a rule:

(saddr == 50.11.69.17/32) accept

meaning “allow all packets coming from your global IP address out”. As the source address of the packet has been changed by the modifier, the packet will be allowed through.

13. Now both the incoming and return packets has been allowed through the firewall. The return packet is sent by the outside interface to the default gateway of your operator, and that will send it further through the Internet to the computer it is destined to.

As you can see, we need to check each ruleset to make sure the packets are allowed through, though many rulesets already allow them and does not need to be modified. And the modify action of the incoming rule also helps our outgoing packet to get back out.

Entering the rules

As you can see we need to enter two rules to allow the data through. One in step 2 above and one in step 9. You enter the rules into the “Additional rules” fields of the security profile page:

LINE Incoming user post dport == 5032 && proto == tcp modify static daddr 192.168.0.31
ET1 Incoming user post saddr == 192.168.0.31 && sport == 5032 && proto == tcp accept

All other necessary rules are already present in the standard firewall ruleset.

firewall/example_2.txt · Last modified: 2010/11/04 13:20 by tibor
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0