Strange behaviour for ICMP (ping) rule on WAN interface
-
@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.
-
Dear @viragomann and @stephenw10 ,
following your suggestions, during the last hour I created the bridge between the WAN and "public LAN (VLAN with VLAN ID 90)".
No IP has been added to the "public LAN".After that, I created a virtual machine on my hypervisor and I connected it to a physical switch port (this port is configured in access mode on VLAN 90).
The uplink port of the same switch is connected to the pfSense "public LAN" interface (the switch port is in trunk mode).I added a test rule (ICMP any to any) both to the "public LAN" interface both to the "WAN".
You can find below a sketch of the current scenario.
I just started some tests, but, unfortunately, I'm not able to ping, from the VM, the y.y.y.1/25 and y.y.y.2/25 IP addresses.
Could you please help me to detect what I'm doing wrong and solve this last issue?Many thanks for your patience.
Mauro -
Do you see any traffic blocked in the firewall logs?
What error is shown when you try to ping?
-
@mauro-tridici
Are you sure that your VLAN works properly?For testing purposes you can assign an IP to the VLAN90 interface directly and try to ping it from the VM. Also try to ping from the switch if it is capable doing that.
-
@stephenw10 at this moment, I don't see any error in firewall logs related to WAN and "public LAN" interfaces. No error during the ping execution. The ping command is in execution without producing output.
I started tcpdump on pfsense "public LAN" interface (IP y.y.y.2/25) and I made some "ping" from VM (y.y.y.5/25). The output of "tcpdump|grep -v ARP" is the following one:
14:32:11.231082 IP y.y.y.5 > y.y.y.2: ICMP echo request, id 18558, seq 982, length 64
14:32:12.231062 IP y.y.y.5 > y.y.y.2: ICMP echo request, id 18558, seq 983, length 64It seems that pfsense receives the request, but it is not able to reply to VM.
Please, note that, on the VM, I set y.y.y.2 as gateway (please refer to the sketch above). -
@viragomann Should I remove the bridge before adding the IP to VLAN90?
Anyway, if you can, please take a look at my last reply to the stephenw10 message.
Thanks.
Mauro -
If it can help, I would like to say that, after enabling the bridge, I was not able to ping the WAN interface with public IP y.y.y.2 although a rule allows to do it.
-
The fact it is trying to ping implies it must have an ARP entry there. Why did you exclude ARP lines? What does it show with ARP?
Do you see anything different trying to ping the gateway?
What firewall rules do you have on the 'public LAN' interface/
Remeber that without an IP on it the system alias 'public LAN net' is not valid so you cannot use it as the source IP. You would see those pings blocked in the firewall log though.Steve
