Messages

I believe there is an issue with WAN to LAN traffic using PRIVATE IP addresses and is documented in the thread link below.

The issue appears to be related to NAT shut off and using PRIVATE IP addresses. However, this is a guess.

Turning off the firewall results in everything working fine. So the routing and PC setup, network addresses are all fine.

Enabling the firewall, permitting all traffic from WAN and LAN side allows LAN to WAN communication.
WAN to LAN communication is blocked.. it should be allowed.
All NAT is disabled.

The private IP addresses should have nothing to do with the issue, unless there is a software glitch where private IPs are being blocked, even though all PRIVATE/BOGON nets are allowed on both interfaces.

This should be a simple configuration to test. This exact configuration worked about 12 months ago with a previous version of OPNsense.



https://forum.opnsense.org/index.php?topic=12018.0

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.

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.

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.

Yes.. Internal IPs.  DO NOT have to have public IPs.. Although the "Internet" rules/policies state private IPs are not allowed on the Internet, it requires ACLs and other mechanisms to specifically filter them out at the ISP level. Routers will route ANY addresses just fine.

Not sure anyone is viewing this topic.. I've posted nearly the exact same issue..

It is not true that routers will not route Private IP traffic. Sure, if you have routers on the Internet they will only pass public IP traffic, but in educational settings, we are using lots of Cisco gear that routes private IPs just fine.  In the situation in this thread, I have found disabling the firewall will cure the issue, but then you have no firewall. However, this proves the routing is working just fine.

The problem is that the solicited return traffic from the LAN seems to be dropped. I haven't put a packet inspector on the LAN side to gather more data to see exactly what is happening. But it seems that if traffic is originated from the WAN side, it won't get returned. If it is originated from the LAN side, things work fine. It appears to be strictly a firewall issue, as disabling packet filtering cures the issue.

So I don't see a solution in this post. I don't believe the answer given is valid in this context. It is quite common inside large organizations to use private IP addresses between sub-orgs and want to have a security appliance; and it is great for educational labs where one is testing the appliance.

Dave

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