Yet another ping problem with Virtual IPs

rebi

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

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

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

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