OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: pbolduc on April 22, 2017, 08:06:19 pm
-
To whom it may concern,
When I change the WAN adapter settings Enable/Disable
- Block private networks
- Block bogon networks
Save the settings the router doesn't recover and prevents traffic from routing out the gateway. The only way to restore routing functionality is to reboot the router.
There are also a few other areas pertaining to NAT that prevent the Router from routing after applying settings and the router only resumes after a reboot. Disabling the WAN interface and re-enabling the interface doesn't correct the problem.
-
You need to give a bit more information on what is beyond your WAN interface.
Bart...
-
I just have a Cable modem plugged in directly in to the WAN port. I'm pretty sure I can reproduce the problem consistently. If you could provide me with a method to report more information I would be more then happy to try it.
I'm also in the process of attempting to install Squid to test as a content filter. However, it appears the squid install doesn't complete after attempting to Download ACL's from a URL and apply them. The Squid service doesn't start and the following Errors show in the event log located here: https://192.168.1.1/diag_logs_proxy.php?type=cache
File /var/log/squid/cache.log doesn't exist.
File /var/log/squid/access.log doesn't exist.
File /var/log/squid/store.log doesn't exist.
The furthest I could make it following the manual : https://docs.opnsense.org/manual/how-tos/proxywebfilter.html was to Step 3.
The Blocklist file I attempted to use was: http://www.shallalist.de/Downloads/shallalist.tar.gz
I have gotten the Squid Service up and running. I didn't realize the prerequisite to enabling this service was to not use "DNS Forwarding" But to install and enable the DNS Resolver by installing "Unbound DNS" Service. Which makes sense because I needed a local authoritative DNS server not a DNS forward service.
-
I would advise to fix the basics before adding more features.
Does the WAN interface get a public IP address from the cable modem? How is it configured? (DHCP/PPP/Static)
Bart...
-
Yes, the routers WAN is set for DHCP. It does obtain an IP from the ISP but the routing between the LAN and WAN port cease until the router is rebooted after saving changes to the WAN interface.
-
Can you recover OPNsense by renewing the dhcp lease? From the console do
# dhclient <name of WAN interface>
Bart...
-
I definitely tried that but not from the CLI. The adapter did release and renewed but still did not correct the problem. I will try from the CLI and report back but i suspect it will end with the same result. Im also sure i attempted pinging the wan interface and gateway but now i cant remember what the outcome was. I will try that again too.
-
Okay, so i get an IP on the WAN port. I can PING WAN IP and WAN gateway ip. But every other public ip replies destination host unreachable. I can successfully release and renew ip using GUI interfaces-->overview-->WAN interface / release/renew ok. I cant ping from interfaces diagnostics ping it returns ping sendto: no route to host
When I run the command you asked me to: # dhclient <name of WAN interface>
It returned: dhclient already running, pid: 74889.
I have also attached as many logs as I could find while it wasn't working.
Disabling and Enabling the WAN interface doesn't correct the problem. Only a system reboot of OPNSense corrects the problem.
-
I have 3 interfaces (Network cards) that I have bridged together to act like a switch on the Opnsense box. I have manually tagged each of the individual bridged interfaces with a VLAN ID of 2. However, after connecting the OPNSense device to my managed switch port with the same tagged VLAN ID of 2, it appears the ports on the OPNSense box aren't being tagged as this enables them access to my management VLAN ID of 1.
When I set my managed switch to discard untagged frames on the port the OPNSense is connected to, it stops all traffic to and from the OPNSense box. I can only assume the OPNSense bridge NIC packets aren't being tagged with a VLAN ID to the managed switch.
Sorry, this is probably my own fault, I'm reviewing my configuration and I may have missed a few steps...
-
*** UPDATE *** Oh my gosh, where to begin? Networking can be so crazy complicated but the solution is always logical and simple.
I was able to get VLAN tagging working with my bridged interfaces and my managed switch. I had two VLAN's on the managed switch. VLAN ID 1 and VLAN ID2. I also setup firewall rules to send traffic from one VLAN1 to VLAN2 but not from VLAN2 to VLAN1. Anyway, mysteriously traffic was somehow going from VLAN2 to VLAN1 without any routing or firewall rules. In fact I got so frustrated I was using DENY permissions to prevent the flow of traffic between the two networks having absolutely no impact. Traffic was still flowing back and forth freely. How was this possible? Well... as it turns out my LAN interface on the OPNSense Router had an IPSEC tunnel setup between the two Routers/VLANs . Traffic was routing out through the WAN interface through the VPN and making its way from VLAN2 to VLAN1. Now the mystery is over and I've disabled my IPSec Tunnel that I had setup a while ago. Crazy frustrating! Sometimes I'm my worst enemy.
Just to recap the concern is:
1) When initially setting up or connecting an OPNSense router, it fails to route, but is immediately cleared up by a system reboot.
-
I think my biggest problem was not binding the bridge interface to the bridge. For anyone interested below is my working config.
Interfaces: Assignments
Bridge: Bridge0 ()
LAN1: EM1
LAN2: EM2
LAN3: EM3
WAN1: EM0
Interfaces: Other Types:VLAN
EM1 VLAN ID 1
EM2 VLAN ID 2
EM3 VLAN ID 2
Interfaces:
LAN1: IP ADDRESS: 192.168.1.1 / 255.255.255.224
DHCP RANGE: 192.168.1.2-192.168.1.30
Interfaces: Other Types: Bridge
Interface: BRIDGE0 Members: Bridge,LAN2,LAN3
IP ADDRESS: 192.168.100.1 / 255.255.255.224
Bridge DHCP Range: 192.168.100.2-192.168.100.29
I use the Firewall:Rules section under the Bridge & LAN1 Interfaces to include a Deny Policy to prevent VLANID 1 from Accessing VLANID 2 and vice versa and I ensure the deny policy is applied at the top before any additional policies.
In conclusion, this setup allows the OPNSense router to have two isolated & private networks which also can be service configured to communicate between the two by means of a firewall policy. This configuration also allows both networks to share the same common internet connection.
Time for a kitkat and a config backup! LOL