[SOLVED] No ping on WAN side

[Tripple_Delta]

Here's my situation:
Router from provider, LAN has 192.168.1.X/24
OPNsense firewall WAN: 192.168.1.2

I'm sitting in between, trying to ping my OPNsense box from 192.168.1.185.
I added a firewall rule to allow ICMP on the WAN port, but no luck.

Wireshark sais:
342   290.452854   CompalIn_f7:cd:d8   Portwell_37:ca:3a   ARP   42   Who has 192.168.1.2? Tell 192.168.1.185
343   290.454010   Portwell_37:ca:3a   CompalIn_f7:cd:d8   ARP   60   192.168.1.2 is at 00:90:fb:37:ca:3a

So I guess my PC nows where to look. However:
348   300.457680   192.168.1.185   192.168.1.2   ICMP   74   Echo (ping) request  id=0x0001, seq=39/9984, ttl=128 (no response found!)

I even added a test rule on my box to allow everything, no luck.

[bartjsmit]

Are you allowing private networks on the WAN interface?

Bart...

[Tripple_Delta]

Yes, Block private networks is unchecked.

[bartjsmit]

Can you ping from OPNsense to 192.168.1.185?

[Tripple_Delta]

Yes, I can ping my PC.  :D

PING 192.168.1.185 (192.168.1.185): 56 data bytes
64 bytes from 192.168.1.185: icmp_seq=0 ttl=128 time=1.694 ms
64 bytes from 192.168.1.185: icmp_seq=1 ttl=128 time=1.445 ms
64 bytes from 192.168.1.185: icmp_seq=2 ttl=128 time=1.447 ms

--- 192.168.1.185 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.445/1.529/1.694/0.117 ms

[franco]

This sounds like another case of requiring "Disable reply-to" under Firewall: Settings: Advanced.

OPNsense is tailored for providing WAN to LANs and this option is normally set to provide consistent Multi-WAN support for internal clients. It is harder if you go at it from the WAN side, but not impossible. :)


Cheers,
Franco

[Zeitkind]

Isn't it possible to add a rule to only disable reply-to for those "local WAN networks"?
I have some setups with multi-WAN _and_ local WAN networks like /248 for in house servers and such. Not sure what will happen to multi-WAN connections if I disable reply-to on those firewalls.
Common are static ISP connections with eg. /248 and one or more additional WAN uplinks (DHCP, cable, VDSL, LTE..) for surfing@squid or failover or simular.

[Tripple_Delta]

Fixed  :)

Thanks Franco

[franco]

Happy to hear, Tripple_Delta. :)

Here's one of mine, it gets added to the WAN rules that are manually set:

pass  in  quick  on $WAN reply-to ( em1 192.168.2.1 ) inet proto tcp  from any to 192.45.67.8 port 80 flags S/SA keep state  label "USER_RULE: NAT "

You could set source (from) to your WAN net, then disable reply-to in the rule itself.
If you need a rule for an IP outside of your WAN (from the Internet) it requires Multi-WAN protection a separate rule needs to be set up underneath.

I can see that NAT rules auto-generate the pass rules that can't be edited which is annoying. If the association is set to none in the NAT rule, the pass rules can be created manually.

I've been looking into several pf issues in the kernel code lately, but I haven't forgotten about this. Previously I wasn't sure, but Ad kept saying it's working as configured, which is a major annoyance, but it's true. Even if patches exist that lax this restriction, they are not in FreeBSD so it makes it unclear wether it's a path to pick up these patches too or try to fix the underlying issue somehow.

I'd love to ignore the same network in the rule, but that also ignores the pass. I'd love to kill the gateway IP, but it'll cause traffic to disappear when the gateway is not set properly.

pf acts as a routing platform on top of the system's routing table especially because of Multi-WAN. Need more time to investigate this... :(