Yet another ping problem with Virtual IPs

rebi · Mar 26, 2019, 6:26 PM

I didn't quite get the workaround idea (BTW using "Automatic outbound NAT rule generation" at the moment). What rule do I have to create and will it take precedence, i.e. do I need to switch the Outbound NAT Mode?

As for the pings, I've just confirmed it's definitely the ICMP identifier as I downloaded something called hrping (googled it) which allows setting the ICMP Id. Whenever I set one and the same ICMP Id I have the problem and once they're different (hrping does this by default) there's no problem ... bloody routers! ... though one could blame Windows as well! Here's an excerpt from Wikipedia I've just read: "The Identifier and Sequence Number can be used by the client to match the reply with the request that caused the reply. In practice, most Linux systems use a unique identifier for every ping process, and sequence number is an increasing number within that process. Windows uses a fixed identifier, which varies between Windows versions, and a sequence number that is only reset at boot time."

stephenw10 · Mar 26, 2019, 8:09 PM

Yes, blame all around there.

So pf can't create the state because everything is the same. If we add an outbound NAT rule on the LAN that then chnages the states to include the NAT but more importantly pf randomises the identifier making it unique.

So first switch outbound NAT to hybrid mode so you can add manual rules. The add a rule like:

🔒 Log in to view

It would be better to specify the source or use !this_firewall but that's not available. As it is if you try to ping the proxy VM from the firewall itself it will NAT that too. But that may not be an issue, certainly not as a test.

Steve

rebi · Mar 26, 2019, 9:10 PM

@stephenw10
Just tested this and it's the same. I've changed the NAT mode and added this rule:
🔒 Log in to view

Grimson · Mar 26, 2019, 9:19 PM

@rebi said in Yet another ping problem with Virtual IPs:

@stephenw10
Just tested this and it's the same. I've changed the NAT mode and added this rule:
🔒 Log in to view

@stephenw10 said in Yet another ping problem with Virtual IPs:

If we add an outbound NAT rule on the LAN that then chnages the states to include the NAT but more importantly pf randomises the identifier making it unique.

He said on LAN and you created it on WAN.

rebi · Mar 26, 2019, 9:34 PM

@Grimson my bad ... here it is but still doesn't work:
🔒 Log in to view

stephenw10 · Mar 26, 2019, 9:38 PM

What happens when you try to ping? Any change at all?

Check the states in Diag > States, filter by icmp.

Steve

rebi · Mar 26, 2019, 9:51 PM

@stephenw10

Nope, exactly the same as before. Until the old state is cleared, the next ping doesn't go through. hrping works flawlessly but it changes ID on every ping request.

Anyway, now that I know what the problem is, I'll simply adapt to the reality and will use another internal IP address for the second ICMP port forward.

I'm happy to test any ideas though ... out of curiosity what would make it work :)

stephenw10 · Mar 26, 2019, 9:54 PM

I'd be interested to see the states on the LAN side. I expect it to show the NAT and the identifier chaging.

But, yeah, it may simply not be possible in which case just move forward with what works.

Steve

rebi · Mar 26, 2019, 10:34 PM

States were not very clear about what exactly was going on so I got for you some packet capture results from LAN:

without the rule
ping IP1 - ICMP Identifier is always 1
ping IP2 - nothing until state is cleared
ping IP2 - ICMP Identifier is always 1

with the rule
ping IP1 - one and the same ICMP Identifier which is a random number, e.g. 3654
ping IP2 - nothing until state is cleared
ping IP2 - one and the same ICMP Identifier which is a random number but different from the one above, e.g. 8346

So, how I understand this ... your idea works but probably too late as the state is already being created with whatever came first to WAN.

Here's why I think it's too late:

ping from my home network - whatever I do, it always creates the state as "<my home ip>:1 -> 192.168.101.2:1"
ping from my office network - it always creates states with random id for each ping "batch", e.g. "<my office ip>:60473 -> 192.168.101.2:60473"
hrping - it sends each ping with a different ID but the state is always created with the ID of the first ping request ... hence I think it's probably too late for the rule to take place.

stephenw10 · Mar 27, 2019, 1:08 AM

Mmm, interesting. Two states are created in the firewall, one on WAN and one on LAN.

It could be the WAN state still giving a problem since the NAT happens before the ACL there so both have the same destination. However the NAT is included in the state so I expect it to still be unique.

Clearly something is still conflicting.

Not really anything else we can do there.

Steve