SNAT rule returns wrong public IP

Hello!

I’ve implemented SNAT rules but when I do a « curl ifconfig.io » the device returns the primary WAN public IP address. Why ?

Thanks for your reply!

David

Does the log show your rule being used when you run the curl command. Make sure you enable the checkbox for logging for the rule while debugging otherwise you won’t see anything.

Hello @bonnietwin ,

In Status > Connections I see that the rule seems to be correctly used : the 192.168.2.27 device use the public IP .238 defined in the rule :

image

Is that correct for you ?

If yes, why when I do a curl ifconfig.io on the 192.168.2.27 device he returns the primary WAN public IP ?

Thanks for your help.

Here is my FW rule for device 192.168.2.27 :

That just shows that a connection has been made. It does not show what is happening to the traffic.

You can do a grep of the /var/log/messages file to search for entries with the IP you have blocked out to see what actions the firewall is taking with those packets.

From your screen shot of the firewall rule I see that the rule in question is number 14. Do any of the rules 1 to 13 also match for that IP and therefore prevent the packets ever seeing your firewall rule.

A simple test of that would be to move that SNAT rule to the top of the rules (position 1) so that any packets will get tested against that first.

Unfortunately, I have no experience with using SNAT rules so I am just providing input on other aspects that might get in the way. I can’t judge if the rule makes sense. Hopefully there are other people using SNAT that can give input.

Just to make sure: is the secondary IP correctly listed in the Alias interface? In other words, if you run:

ip addr show dev red0

do you see both public IPs?

From your screen shot of the firewall rule I see that the rule in question is number 14. Do any of the rules 1 to 13 also match for that IP and therefore prevent the packets ever seeing your firewall rule ?
A simple test of that would be to move that SNAT rule to the top of the rules (position 1) so that any packets will get tested against that first.

No. I’ve moved the rule to number 1 but the result is the same…

You can do a grep of the /var/log/messages file to search for entries with the IP you have blocked out to see what actions the firewall is taking with those packets.

All I see is that there’s no …SRC=x.x.x.238 as if the rule doesn’t work… There should be this kind of entry right ?

Yes !

if you run ip addr show dev red0 do you see both public IPs?

Yes !

I would expect so as you have the rule with logging enabled. Just to check, you have enabled the rule? Generally the rule is auto enabled when you save it but worth confirming.

If you don’t find the x.x.x.238 then look for the 192.168.2.27 source value and see if that gives any insight.

Building on @bonnietwin’s proposal, you can display all chains within the NAT (Network Address Translation) table by employing the command detailed below:

iptables -t nat -L

Here’s a brief explanation of this command:

  • iptables is a command-line utility in IPFire used to configure firewall rules.
  • -t nat specifies that you want to work with the NAT table.
  • -L instructs the command to list the chains and associated rules in the specified table.

Executing this command with root privileges will showcase all chains present in the NAT table. This includes the default chains (PREROUTING, INPUT, OUTPUT, POSTROUTING) and any chains designed by IPFire developers. I suspect your rule might be located in the NAT_SOURCE chain. To inspect this, use:

iptables -t nat -L NAT_SOURCE

This command will enable you to see the rule and determine whether any packet has navigated through it. You can also access this information through the Web User Interface at /Firewall/Iptables. The NAT table is the last one listed and a drop-down menu provides a view of all the chains. Selecting the chain, will show both the rules and the packets.

1 Like

can you ping ping [alias IP] from inside and then outside your network?

can you ping ping [alias IP] from inside and then outside your network?

All public IPs aliases are responding from inside and outside the network.

Besides, I have services running on these IP aliases and everything is working fine. What really bothers me is for my mail server and my self-hosting servers which do not return the correct IP against the DNS A record (returns primary RED WAN IP instead of IP alias despite of SNAT rule(s))…

The “none to” in the log message could mean that no specific rule or policy was matched for the outgoing traffic to the specified public ip. Essentially, the firewall did not find a matching policy (pol) for the outbound traffic, so it used the default or fallback rule, often referred to as a “none” or “any” rule.

I think you should troubleshoot your rules. I would setup a test IPFire machine where you eliminate all the rules you have in the firewall but this SNAT and see if that will pass through correctly.

If you cannot solve the problem, I would open a issue report, posting both the rule as you have set it up using the WUI and the content of iptables -t nat -L. You probably need a more competent help from someone that understands the firewall (which is not me).

The rule you’ll need to implement should resemble the following format:

iptables -t nat -A NAT_SOURCE -s 192.168.2.27 -j SNAT --to-source PUBLIC_IP

This command is structured as follows:

  • iptables initiates the command-line firewall utility.
  • -t nat signifies the operation on the ‘nat’ table.
  • -A NAT_SOURCE appends the rule to the ‘NAT_SOURCE’ chain.
  • -s 192.168.2.27 stipulates that this rule applies to traffic originating from 192.168.2.27.
  • -j SNAT indicates that the packets that match the rule will undergo Source NAT.
  • --to-source PUBLIC_IP adjusts the source address of the packet to PUBLIC_IP (of course, your real aliased secondary IP) before it leaves the firewall.

To verify if such a rule exists, or to find any other rules involving 192.168.2.27, you can inspect the output of iptables-save with a grep command:

iptables-save | grep "192.168.2.27"

The above command will output any line in your iptables rules that include 192.168.2.27, thereby helping you confirm the existence of the rule or discover any additional rules related to this IP address.

1 Like

Hi @cfusco ,

Thank you for your help.

Here the result of iptables-save | grep "192.168.2.27" :