WAN to LAN traffic not working

[Crab]

I'm using OPNsense (latest.. v19.1.4) in an educational setting for instruction to Community College level students.. as such have all private networks.. here is setup.

172.16.0.x [WAN] -- [OPN] -- [LAN] 10.1.1.x  (all /24)

Block Bogon/Private nets both unchecked.
NAT is DISABLED
DHCP disabled (using all static addresses)
WAN machine I am using has gateway pointing to OPN

Inside LAN I have an SSH service. I am trying to demo some firewall rules to allow unsolicited traffic from WAN side. I set up rules to allow ICMP on WAN interface and expect to ping a host on the 10 network. I set up a rule to allow SSH on WAN side and expect to log into SSH service.

So from WAN side:
   ping 10.1.1.2
   ssh test@10.1.1.2

Both fail even though I have WAN rules to permit all IPV4 traffic thru.


 If I disable firewall filtering.. both tests above work, so router is working fine; as is PC config.

If I reverse the situation and put the SSH service on WAN and put the rules on the LAN side, I can access SSH fine. Same with ICMP rule.. if moved to LAN, lan machines can ping a WAN machine fine.

  Ping 172.16.0.183
  ssh test@172.16.0.183  both work fine

Am pretty sure nothing is mechanically wrong, but I suspect there is something going on inside that I am unaware and wonder if anyone can let me know what is going on for my own education.

I tried looking at logs and can see the SSH traffic going into the WAN, out the LAN to the LAN SSH service, but nothing is logging coming back from the LAN. It is as if the return SSH frames are dropped before getting into the log.

I changed darned near every setting in Firewall -> Advanced and nothing seemed to work.

I will say that I did these tests a year ago with v17 (or 18) of OPN and it did work then. Don't think I am doing anything different.

Any suggestions appreciated.

Dave Crabbe
NSCC

[Crab]

Yes.. there is something going on here which is not obvious.. because OPN is very complex, I don’t think it is a bug (although small chance it might be) but it does not seem easy to determine why the WAN-> LAN traffic doesn’t get returned. It would take some deeper knowledge of how OPN is working.

[newsense]

Can you post a screenshot of the WAN rules ? Or both really, shouldn't matter for a demo setup.

[Crab]

2 interfaces: WAN & LAN.. Block Private/Bogon both unchecked on both interfaces
OUTBOUND NAT is OFF

If I 'disable all packet filtering", then I can hit SSH service from WAN to LAN (and I can do LAN to WAN SSH)

With firewall 'on' and rules as shown, I can do LAN to WAN SSH, but the WAN to LAN ssh does not work; nor does pinging 10.1.1.2 (LAN PC)

It should have nothing to do with private IP addresses. Obviously the routing is working fine and the machines are configured correctly as everything works once I disable the firewall.

All Advanced setting on firewall are in default value.

I'm calling it a bug...  It's a very simple setup.. 4 students get exactly same behaviour. I have latestOPN 19.1.4.

[Crab]

If I were to guess, I’m guessing that there is a bug where either the WAN or LAN side is blocking private IP addresses even though the settings are unchecked in both interfaces.

[millburger1]

Fortunately I only spent an hour trying to figure out why my brand new install of OPNSense could pull an WAN IP, would give me a valid DHCP address (v4 & v6), could ping from OPNSense, etc. Everything looked great. Every test I could think of worked perfectly... unless I used my Macbook to hit the Internet. Didn't matter what browser, terminal, nothing. Could not get from LAN to WAN from client. Changed from 192.168.3.x to 10.0.0.x. Dead ends everywhere. Knew it wasn't Unbound, the firewall, rules, because I had not set any up!!

Turns out the Network Settings for Thunderbolt Ethernet had 192.168.1.1 hard-coded in the list of DNS servers. Had to manually remove with the "minus" button. Everything lit up like a Christmas tree. No clue when that got set. Not normally an issue because I'm always on wifi, but my bench PC was busy with another task, so I thought, WTF... how hard can this be to figure out?? Turns out, kind of a PITA.



tl;dr: Could not access the internet after OPNSense default install. The wrong DNS was hard-coded on the client.