Strange behaviour for ICMP (ping) rule on WAN interface
-
Dear Users,
I'm simply trying to add a firewall rule in order to allow ping to pass from "Internet" to a particular target host (with a public IP address) that is living behind pfSense 2.5.2.
Every other rule (rule for SSH, for example) works as expected, but ping rule behaviour is very strange.
If I set the following rule "PASS any source with ICMP protocol (echoreq, echorep) to the destination target IP", the rule doesn't work.
If I set the following rule "PASS target IP with ICMP protocol (echoreq, echorep) to any destination", the rule works.What I'm doing wrong? What is the logic I should follow?
Could you please help me to understand correctly what is happening?
Please take a look to the attached picture to see all other enabled rules.rule that is not working:
rule that is working:
Thank you in advance,
Mauro -
@mauro-tridici said in Strange behaviour for ICMP (ping) rule on WAN interface:
I'm simply trying to add a firewall rule in order to allow ping to pass from "Internet" to a particular target host (with a public IP address) that is living behind pfSense 2.5.2.
The host behind pfSense has a public IP? So your WAN is bridged to an internal interface or do you have a public subnet behind?
If I set the following rule "PASS any source with ICMP protocol (echoreq, echorep) to the destination target IP", the rule doesn't work.
If I set the following rule "PASS target IP with ICMP protocol (echoreq, echorep) to any destination", the rule works.Is the "target IP" the same in both rules, or once the source and once the destination?
-
Yes, it's hard to see how that could match unless your WAN is a bridge.
You shouldn't need to have echorep set on either of those rules. Replies will always be allowed if the requests are passed. It could be confusing things here though if it's matching and passing the replies specifically though. That would imply that the requests are going via some other route.
Steve
-
@viragomann many thanks for your reply and sorry for my late answer but I had some problem connecting to the forum site today.
Yes, the host behind pf Sense has a public IP.
WAN is not bridged to an internal interface, I have a public subnet behind
the "target IP" is the same in both rule, it is the host with the public IP. -
@stephenw10 thank you for your reply. I will check if the requests are going via some other route.
-
@stephenw10 could you please show me how to create a bridge with the WAN? Could you explain how I can do it? Thanks
-
You should not use a bridge if it's a routed subnet. That was just the only way I could imagine a rule on the WAN where the target IP is the source ever matching traffic.
Are you sure it's on the WAN?
Are you sure it's that that's passing it?
Check the state table when the ping is running. What intrefaces do you see states on for that IP?
Steve
-
@stephenw10 @viragomann Hello guys, thanks to your support I was able to identify a configuration error.
So, I decided to start from beginning following the instructions contained in the following links:
https://docs.netgate.com/pfsense/en/latest/firewall/additional-ip-addresses.html
I'm in this use case (mentioned in "Single IP subnet on WAN" section):
"To assign public IP addresses directly to hosts behind the firewall, a dedicated interface for those hosts must be bridged to WAN. When used with bridging, the hosts with the public IP addresses directly assigned must use the same default gateway as the WAN of the firewall: the upstream ISP router. This will create difficulties if the hosts with public IP addresses need to initiate connections to hosts behind other interfaces of the firewall, since the ISP gateway will not route traffic for internal subnets back to the firewall."For this reason, it seems that the right solution is a bridge between WAN and "PUBLIC LAN":
https://docs.netgate.com/pfsense/en/latest/bridges/index.html
I'm in this use case (mentioned in "Internal/External bridges" section):
"An Internal/External type bridge, also known as a “transparent firewall”, is used to insert a firewall between two segments without altering the other devices. Most commonly this is used to bridge a WAN to an internal network so that the WAN subnet may be used “inside” the firewall, or internally between local segments as an in-line filter. Another common use is for devices behind the firewall to obtain IP addresses via DHCP from an upstream server on the WAN.In a transparent firewall configuration the firewall does not receive the traffic directly or act as a gateway, it merely inspects the traffic as it passes through the firewall."
I just created a "PUBLIC LAN" on pfSense and I'm ready to create the bridge between "PUBLIC LAN" and "WAN".
But, before proceeding, I would like to ask you if enabling the bridge will disrupt the traffic running on other interfaces/LANs and if it will create some inconvenience on the NAT settings that are involving the WAN and some other LAN interfaces.If it is not the right solution for my needs, what is your suggestion?
Sorry for this long message and many thanks for your patience.
Mauro -
Anyone had the same needs?
Could you please help me?
Thanks
Mauro -
If the IP on the target host is inside the WAN subnet then, yes, you will need a bridge because that cannot be a routed subnet.
Adding the bridge should not cause any disruption to traffic on the WAN. It may restart services on it, VPN tunnels perhaps, by they should come back immediately.
Steve
-
@stephenw10 thank you very much for your reply.
In the Bridging link page I read this:"NAT is not possible with this style of bridge because NAT requires the traffic to be addressed to the firewall’s MAC address directly in order to take effect. Since the firewall is not the gateway, this does not happen. As such, rules to capture traffic such as those used by a transparent proxy do not function."
This is the reason why I asked if enabling the bridge can cause some problem to the existing Nat rules between wan and other LANs.
So, you can confirm that I can proceed without problem?Thank you
-
@mauro-tridici
It's still not clear to me, how you get you WAN IPs. What is the bridged subnet behind pfSense?
@stephenw10 mentioned already, if it's routed to your primary WAN IP, a bridge is not the proper way to set it up. You could use proxy ARP in this case.Is there really a need to have public IPs on the server itself behind pfSense?
-
You cannot NAT the traffic across the bridge.
It doesn't affect the outbound NAT from other internal subnets to the WAN IP though.
Steve
-
@viragomann @stephenw10 you can find in attachment a sketch describing the scenario I'm trying to create.
From the top to the bottom, you can see:
- the ISP, that is connected to our router with a point-to-point link;
- our router, that have 2 IP addresses (one IP address for the point-to-point link and the first (#1) public IP of the public subnet that ISP provided us)
- the pfsense router that acts as firewall (the second (#2) public IP has been assigned to the WAN interface of pfSense)
- the existing LANs
- the new LAN ("LAN with public IP behind the pfsense") that I created in order to group every hosts with the public IP.
I created the "LAN with public IP behind the pfsense" without doing anything else. So, I don't know if the LAN is a "routed" LAN; when a lan is defined "routed"? (sorry for my stupid question, but I'm a newbie...).
My ultimate goal is to protect hosts with IP address using existing firewall.
-
@stephenw10 this is definitely the answer I was looking for. the bridge and related limitations impact only the bridge itself.
So, the existing NAT rules, involving WAN and other LAN interfaces, are not involved.Many thanks,
Mauro -
@mauro-tridici
A routed subnet means, that the ISP routes the subnet to your primary WAN IP.
This is applicable to your WAN network y.y.y.0/25 for instance. This is routed to the WAN-side routers IP.If the "public LAN" was routed to your WAN IP it would be routed to the outer router IP as well. Additionally it would need to route on the ISP router to point it to the pfSense WAN IP.
Is the "public LAN" a separate subnet or are the IPs part of y.y.y.0/25?
If the latter case you can go with bridge WAN <> public LAN and you should be able to access the IPs inside from the internet without issues. Proper firewall rule on WAN presumed.
Otherwise it needs to be routed to your WAN IP by the ISP to use it behind pfSense. The configuration is well described in the docs: Routing Public IP Addresses. -
Yeah, it looks like you do have a routed subnet there, the /25 is routed to you over the /30.
But you can't use it as a routed subnet in pfSense because you have some other router upstream and the /25 is on the pfSense WAN directly.
In that situation you would have to bridge it to use the public IP on servers directly.A much better setup though would be to remove the upstream router so pfSense uses the /30 on it's WAN. Then you can use the /25 directly on an internal interface as a routed subnet.
That may not be possible/practical.Steve
-
@viragomann thank you very much for the detailed explanation. The "public LAN" is not a separate subnet and related IPs are part of y.y.y.0/25.
So, I can proceed with the bridge WAN <> public LAN.
Thanks again for everything you have taught me, I really appreciated.
In any case, I will study also the content of the link you provided.Tomorrow morning I will apply the new configuration to the pfSense instance.
Kind regards,
Mauro -
@stephenw10 thank you for sharing with me your know-how.
I will save this discussion to a PDF file because it is very interesting from the educational point of view.You and @viragomann have helped me a lot!
Thanks,
Mauro -
@mauro-tridici said in Strange behaviour for ICMP (ping) rule on WAN interface:
In any case, I will study also the content of the link you provided.
That's not applicable for you since you say
The "public LAN" is not a separate subnet and related IPs are part of y.y.y.0/25.
In this case you can only go with a bridge or as Steve suggested kick out the ISP router if possible.
