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
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 :
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.
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 ?
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:
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.
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.