Allowing Public IP to LAN server

I am trying to do some testing with the intention of replacing my current firewall with IPfire. I have a /29 block of IP addresses and I would like to forward one of them to an internal server and port forward some of the main IP’s ports to another. I have reasonable knowledge of iptables but I have some questions.

For this exercise I am setting my WAN IP as 172.17.3.1/24 (this is testing on a spare LAN subnet of my main router), and a LAN subnet if 172.17.4.1/24.

Now I would like to forward in its entirety 172.17.3.2 to 172.17.4.2. Please can you confirm how I should be doing this? What I’ve done is:
1 - create an alias “test” of 172.17.3.2
2 - create a firewall rule of:

  • Source - Standard Network - Red
  • NAT - Use NAT, Destination NAT, Firewall interface - test
  • Destination 172.17.4.2
  • Protocol Any

Is this correct?
Do I need an SNAT rule as well so all traffic originating from 172.17.4.2 appears externally to come from 172.17.3.2?
What is the function of the Firewall radio buttons in the Source and Destination sections?

I am then trying to set up a port forward of the main IP, 172.17.3.1, tcp ports 9981-9984 to 172.17.4.3. What I’ve done here is:

  • Source - Standard Network - Red
  • NAT - Use NAT, Destination NAT, firewall interface - Automatic
  • Destination - Destination Address - 172.17.4.3
  • Protocol - TCP, Destination Port 9981:9984

In this rule I have not specified the external IP. Does it pick it up from the Red interface? Is the rule OK

I have another server (which currently is also the firewall) and it needs to have tcp ports 25, 80, 443, 587, 993, 1875 and 51413 forwarded to it. Can it be done in a single rule? I have tried and failed to use multiple ports directly. I have set up a Service Group with the required ports, but I don’t see how to then use the Service Group in a Port Forward firewall rule. Can it be achieved or do I need a load of individual rules?

TIA, Nick.

I think this is going to be important to you.

I’ve seen that doc but it does not say how to use the aliases. For example, the Alias appears in the Source > Firewall dropdown and the NAT > Firewall Interface (and the Destination > Firewall which seems to be irrelevant to this issue). What is the function of the two dropdowns and have I chosen the right one?

Also do you have answers for the other questions, like do I need an SNAT rule, my Port Forward rule which does not use an aliased IP, and my multiport port forward questions?

re reading your post.
And I think a drawing of what your trying to do is in order.
Not sure what your doing.

2 Likes

This is the rough idea.

172.17.3.1/24 (WAN)
		|
     IPFire
	    |
172.17.4.1/24 (LAN)
        |
        |-- 172.17.4.2 Sia Server responding to external 172.17.3.2 
		|   also outbound traffic appearing to come from 172.17.3.2
		|
		|-- 172.17.4.3 walled-test server port forward tcp 9981:9984 from 172.17.3.1
		|
		|-- 172.17.4.4 Old Server port forward tcp ports 25, 80, 443, 587, 993 etc
		|
		|-- 172.17.4.5 Sia test Server responding to external 172.17.3.5 
		|   also outbound traffic appearing to come from 172.17.3.5
		|
		|-- LAN PC's etc

The WAN subnet will be a proper /29 subnet when it goes into production.
IPFire will take over DNS and DHCP duties from the old server and I have bulk loaded the hosts and static leases.

hope this helps.


The part that reads “All”
will have a drop down to select the external IP you would like to use.
this only appears if you have a fixed WAN ip.
Than your port forwards can be to different servers.

I’ve had to make some major edits to my diagram. I had the WAN IP wrong by 1 (.1 is the gateway) and I’ve changed the Sia Server to wan .6 and lan .6 as wan .2 is the normal WAN address. I apologise.

172.17.3.2/24 (WAN)
		|
     IPFire
	    |
172.17.4.1/24 (LAN)
        |
		|-- 172.17.4.3 walletd server port forward tcp 9981:9984 from 172.17.3.2
		|
		|-- 172.17.4.4 Old Server port forward tcp ports 25, 80, 443, 587, 993 etc
		|
		|-- 172.17.4.5 Sia test Server responding to external 172.17.3.5 
		|   also outbound traffic appearing to come from 172.17.3.5
		|
        |-- 172.17.4.6 Sia Server responding to external 172.17.3.6 
		|   also outbound traffic appearing to come from 172.17.3.6
		|
		|-- LAN PC's etc

As far as I can see the FORWARD and DNAT rules are correct, but I am not using the Destination > Firewall dropdown as you indicated:


In the Firewall dropdown there are only Red, Green and the Red aliases, so I don’t think it is right to use it or the LAN destination IP does not get specified anywhere. This is what I have:

I also don’t see an SNAT rule so any packets originating from 172.17.4.6 will probably appear on the WAN with the WAN IP 172.17.3.2 and not 172.17.3.6, but I’m not sure. Do I need to add a SNAT rule?

In the NAT section
use Source NAT
you have Destination NAT (port forwarding) selected.

I have a feeling you are missing what I am doing. The rule I’ve shown DNATs an external IP to an internal server in its entirety (all ports, all protocols). I was hoping you could confirm it as being correct as it does not use the Destination > Firewall dropdown as you indicated in your earlier post.

At the same time, I would have thought this would set up a corresponding SNAT rule automatically but it does not. Why, if forwarding an external IP in its entirety to an internal IP, would you not normally want an SNAT rule? In which case shouldn’t IPFire do it for you automatically?

I’ve updated the Service Groups documentation to point to how to use Service Groups in the firewall.

This is incorrect if you want to reach the IP from the internet. (You have currently selected that the connection come from the red network.) Try “any” here.

1 Like

I’ve tried changing Source - Standard Network - Red to Any. It only seems to make a change to the FORWARDFW chain from (removing irrelevant rules):

Chain FORWARDFW (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  red0   *       0.0.0.0/0            172.17.4.6

to:

Chain FORWARDFW (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0            172.17.4.6

With a single LAN. I don’t think that makes any difference as all packets will be coming in through red0 anyway? Unless it is needed for the case of another LAN IP using the WAN IP. I am used to a SNAT rule to cover that situation.

You are correct. At my last test with “standard network red” the source IP was entered with the RED network. Now it is 0.0.0.0/0 wich is correct. so this doesn’t care.

1 Like

This only works with a static WAN ip.

1 Like

That is what i am using. Red0 is 172.17.3.6 but for the above rules I aliased 172.17.3.6, so this is a static IP but no SNAT rule gets created. See the mini-diagram at the top of Allowing Public IP to LAN server - #7 by nickh.

This is all a got…
all protocols is a allot

Similar to the documentation you linked to, but I have a standalone server (more than 1 actually), supplying services to the internet. It can both originate traffic and receive traffic similar to the mail server example. It also runs its own firewall. I also happen to have a block of IP addresses and I wanted to use them in a similar way to how I do with my current ClearOS firewall. I wanted to push all traffic to 172.17.3.6 to this server rather than have to fiddle around with a number of firewall rules. To me it makes sense to forward everything to the standalone server and let that server’s firewall handle the firewalling. I do need it that traffic originating from the server appears with the .6 WAN IP address and not red0’s IP address. In ClearOS I can set up a single rule which achieves all this - the DNAT, SNAT and FORWARD rules - and have to use fewer fields to achieve the same. In ClearOS, all I do is specify the Public IP, Private IP, check the All Protocols box and give the rule a name. IPFire is quite complicated by comparison and effectively requires some knowledge of iptables and the underlying tech.

I just have to move away from ClearOS as it goes end-of-life this summer and has not been maintained for 18 months (I used to be a maintainer).

How are the iptables rules constructed in ClearOS, based on what definitions?

Not sure this is helpfull.

There are different menu options, Incoming, Port Forward, 1 to 1 NAT, Egress etc., rather than a single Firewall Rules menu. Here is a screenshot of the 1-to-1 NAT:


From that it creates a conventional PREROUTING DNAT rule, a FORWARD rule, an SNAT rule for traffic originating from the server, and an extra SNAT rule for hairpin traffic. Very simple.

Having said that, there are bugs and before I left I did not get to release an update to fix them. There is now no one left to maintain the system. I am running a pre-release version of what the update should have been.

The way to get round the hairpin issue is to create an SNAT rule for all traffic originating from the LAN subnet with a destination of the WAN IP and SNAT the traffic to the IPFire LAN IP. This is the ClearOS HAIRPIN chain in the NAT table:

Chain HAIRPIN (1 references)
 pkts bytes target     prot opt in     out     source               destination
11074  563K RETURN     all  --  *      *       172.17.2.51          0.0.0.0/0
   27  1911 RETURN     all  --  *      *       172.17.2.40          0.0.0.0/0
    0     0 RETURN     all  --  *      *       172.17.2.5           0.0.0.0/0
    0     0 SNAT       tcp  --  *      *       172.17.2.0/24        172.17.2.41          tcp dpts:9881:9884 to:172.17.2.1
    0     0 SNAT       all  --  *      *       172.17.2.0/24        172.17.2.5           to:172.17.2.1
    1   341 SNAT       all  --  *      *       172.17.2.0/24        172.17.2.40          to:172.17.2.1
   32  1760 SNAT       all  --  *      *       172.17.2.0/24        172.17.2.51          to:172.17.2.1

I don’t know if this HAIRPIN chain made it to public release in ClearOS, but if it didn’t, something similar is done in the POSTROUTING chain.

The RETURN rules are to exclude the traffic originating on the servers being SNAT’d in the HAIRPIN section. They get SNAT’d later to their WAN IP.