Yet another ping problem with Virtual IPs
-
@rebi said in Yet another ping problem with Virtual IPs:
Yes, whenever I alternate the pings first time I have between 1 and 4 failed pings and these pings are captured as requests on WAN but not LAN ...
Show me.
-
I can only see it varying by source address if you have some other rule(s) in place using those.
Steve
-
-
Nope, except the default rules all I have is 4 rules which allow OpenVPN (UDP to "This Firewall"), ICMP and HTTP/HTTPS (TCP to Reverse Proxy Internal IP) + 2 1:1 rules for the Virtual IPs.
Thanks!
-
If it was some sort of ARP issue I'd expect to see pfSense ARPing for the target in the LAN side pcap. But I can't see how that could happen since the internal VM is already in the table as the target for the previous forward.
You can PM the pcaps to us if you need to.
Steve
-
@stephenw10 Thank you!
I'm not sure how to send one on this particular forum software (nodebb) ... seems like there are chats instead of regular PMs which are restricted -
How, exactly, are the 1:1 NATs configured?
-
Interface External IP Internal IP Destination IP
WAN VIP1 192.168.101.2 *
WAN VIP2 192.168.101.2 * -
That is not 1:1 NAT. That is 2:1 NAT.
-
Yes. The port forwards should override that if there is some problem there but only inbound. There might still be conflicting outbound NAT causing an issue.
Try disabling the 1:1 NAT rules and using port forwards only there.
Steve
-
Or put another address on the target server and 1:1 NAT the VIPs to their own addresses.
-
Yes, you're right :/ ... I'll try either using port forwards or setting up another internal IP for the second 1:1 NAT (will report the result tomorrow as I have to do it overnight)
-
Actually ... isn't 1:1 NAT simply a more convenient way of port forwarding everything to the specified destination?
(BTW outbound NAT is set to "Automatic outbound NAT rule generation")Anyway, I've disabled 1:1 NATs and created separate HTTP/HTTPS/ICMP rules for each Virtual IP (without associated rules as these already exist). Unfortunately, I experience the very same behaviour, i.e. it still works just fine from my office network but alternating pings fail as per the description above from my home network.
-
I've just added a temporary local IP address on the reverse proxy VM (ip a add ...) and I've changed one of the ICMP port forwards to go to the new local IP address. I've also run iptraf on the VM to be sure that it's the VM which handles the ICMP replies, not pfSense.
With this configuration, as expected, everything works normally (even alternate pings from my home network).
Am I missing something from a conceptual point of view?
I should be able to port forward to the same internal IP, moreover it already works with HTTP/HTTPS traffic ... -
I suspect this is a state issue. pf is trying to open a state on the LAN interface with a source and destination IP that are identical to those of an existing state. With a TCP connection it also using the source and destination port and since the source port is random that will be different to any existing state.
1:1 NAT rules forward all ports the same as a 1-65535 port forward would but it also NAT's traffic outbound from the internal target to the external IP. Obviously that can't happen to two IPs so one rule will fail there. I believe the first 1:1 rule will win.
If you are doing this just to provide a ping target for external users it's probably easier to have pfSense respond to the pings on the VIPs directly and forward only TCP traffic to the proxy.
Steve
-
I don't believe this would be the cause ... ICMP packets should be routable just like TCP and UDP which work ok (well, technically I think ICMP is just an application protocol on top of IP which is routable). Also, if this was the case I would expect it to work intermittently but it works flawlessly from my office network.
As far as I understand, 1:1 NAT is all about incoming traffic and the part of the outgoing traffic that should go out from WAN originating from the associated VIP. Could it be that I need to change the "Automatic outbound NAT rule generation" to, say, "Hybrid Outbound NAT rule generation" and create a manual rule for ICMP? Anyway, I still don't get how it works from one place and not another ... does it work ok when you ping these IPs from your network?
As for the pfSense answering the pings, that simply defeats the purpose of having the ping as it will only let users know whether pfSense itself is working not the services behind it.
-
Having looked into this further I'm certain it's a state issue.
If you look at the failed packet capture the incoming ping requests are all using ICMP identifier number '1'. pf uses that in the state it opens in the same way it does ports for TCP/UDP. It can't open a state on LAN with the same source, destination and identifier as one that exists so nothing passes until the previous state times out.
If you test remotely from behind a difference pfSense it will randomise the ICMP identifier when it outbound NATs the traffic. That means when it arrives at the port forward the two pings have different identifiers and two states can be created. No problem.
It appears that when you are testing and seeing failures the client you are testing from is using the same identifier for all pings. And the router you are testing behind is not randomising the identifier on the way out.
Nothing we can do about that in the pfSense forwarding those pings.
Interesting. Never hit that before.
Steve
-
Hmm, you could maybe have it outbound NAT the traffic to a different internal IP for ICMP only. That would randomise the identifier and allow it.
Ugly but...might work. -
@stephenw10
Aaah, that makes sense now! Spot on!!! :)Could it be because of a double NAT? ... When I think about it, I have a GPON that handles fibre optic and an IPTV box plus my router are connected to that GPON. My router does have an internal IP on the WAN interface. I don't have access to that GPON ... at least legally (I know the account though), as it's controlled by my TV & Net provider. Probably the guys whom I asked to test do have similar setup.
Anyway, I'm extremely grateful that you, guys, put a lot of effort into dealing with my problem!
Thanks and have a great week!
-
No problem. Interesting case.
I'd be interested to see if that outbound NAT workaround allows the pings. That would confirm itYou would see the identifier numbers changed in the state table.
Steve
