Messages

I did notice Kea seems to lack the ability to do two things (which are probably the same thing):

- Custom DHCP options
- Set a DNS server

Am I missing a setting in the UI?

We are stuck on ISC until the Kea interface supports multiple arbitrary DHCP options. I looked at doing a PR to add this but the config syntax for Kea is very byzantine.

All those notices are expected in a typical site-to-site setup. Make sure that `/usr/local/etc/swanctl/swanctl.conf` is populated with expected values; if not maybe ensure the P1 and P2 entries are enabled?

I've been migrating from legacy connections this week and the generated config for both ends up being almost identical; I don't deal with dynamic IPs but I would guess you should just be able to use a domain name instead of IP address for the far side.

What helped me was looking at the contents of `/usr/local/etc/swanctl/swanctl.conf` with the legacy connection and then working towards that in the new connection. The web UI for new connections is aligned very closely to the layout of the config file.

Current ASA firmware can do up to DH group 31

Folks, "no proposal chosen" means there's a mismatch with your P1 settings. Under VPN/IPSec/Advanced Settings, bump up "Configuration management and plugins" logging to control instead of audit. Try to connect and check logs. You should see entries like this, showing what the client tried to use versus what the server can support. If there's success it will tell you what proposal was selected. Otherwise, it will give you "no proposal chosen" error.

Code Select Expand


2023-03-15T20:44:38-06:00 Informational charon 11[CFG] <4> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
2023-03-15T20:44:38-06:00 Informational charon 11[CFG] <4> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
2023-03-15T20:44:38-06:00 Informational charon 11[CFG] <4> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048


There's been a few messages about this over the years but I haven't seen anyone actually say they've gotten it working. A TFTP proxy is part of the core BSD OS so it's just a matter of getting it configured and running.

Does anyone have a step-by-step guide that will let me access a remote TFTP server through an OPNSense box?

Ok, hit save again and it worked (or, at least I'm seeing requests on the LDAP server.) There seems to be some weirdness with saving settings, I noticed MOBIKE support acting up as well (comparing contents of ipsec.conf config file to the checkbox in the web UI.) Will try to reproduce and file a bug report.

Why can't I delete my post?

Having some issues getting this setup. If I use local authentication it works no problem. Using my configured LDAP server does not work; logs on the LDAP server indicate the router doesn't make a connection attempt. The only thing in the log files is this in /var/log/audit.log:

Oct 25 17:32:27 calgary audit[48186]: user mike failed authentication for ipsec on OPNsense\Auth\Services\IPsec via OPNsense\Auth\Local 
Oct 25 17:32:27 calgary audit[48186]: user mike could not authenticate for ipsec. [using OPNsense\Auth\Services\IPsec + OPNsense\Auth\Local] 

And this in /var/log/ipsec.log:

Oct 25 17:32:27 calgary charon[19217]: 07[IKE] <con4|9> XAuth pam_authenticate for 'mike' failed: System error 
Oct 25 17:32:27 calgary charon[19217]: 07[IKE] <con4|9> XAuth authentication of 'mike' failed 

Does anyone have any experience with this setup? Any way to enable some authentication debugging to see if it's working as expected? From the log entries I have, it seems like it's only using local.

I recently replaced a pfSense router with one running OPNsense, and I have an IPsec tunnel to another network (whose router still runs pfSense, though I doubt that matters here).  The tunnel is working: from computers on my LAN, I can ping IPs on the remote LAN using their private addresses.

However, I can't ping the other network from the router itself.  Only from other computers on my network that communicate through the router.

I encountered the same problem back when I was running pfSense, and resolved it using the workaround documented here: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html — in short, create an unmonitored gateway on the LAN interface using the router's LAN IP, and add a static route to the remote network through that gateway.

I've set up the same thing in OPNsense, though, but it doesn't seem to work: pings to the other network from the router still don't get any replies.  Looking in the firewall log's live view, the ping attempt shows up with the router's WAN IP as the source and the remote LAN IP as the destination, which is the default behavior that the static route is supposed to change.  (The firewall log shows the traffic as having been passed, which isn't surprising since this is a routing problem, not a firewall problem.)

Has anyone else done this sort of thing?  Is there a configuration step that I'm missing, maybe something that wasn't needed in pfSense?  I'm new to OPNsense so I don't know whether this is an actual difference between the two systems, or if it ought to work and I'm just doing something wrong.

Did you see my post from last week? https://forum.opnsense.org/index.php?topic=20868.0

Ok figured it out and got it working. Under advanced firewall settings, there's a checkbox labelled "Disable automatic rules which force local services to use the assigned interface gateway." Uncheck it and the OPNsense box can reach things on the other side of the tunnel.

Curious if you were ever able to get this working? I'm in the same boat. I need to run a local BIND server on the OPNsense box, and it needs to talk to primary DNS on the other side of the tunnel.

The trick of adding a gateway and static route pointing to it has always worked for me on pfSense. I thought I remembered having to enable `net.inet.ip.redirect` in tunables as well, but that doesn't seem to change anything.

This issue of not being able to pass traffic mysteriously resolved itself after a reboot, despite identical firewall rules. But this misclassification of packets as coming from wrong interface continues to cause problems.

Observe the following firewall log excerpt, igb2 is the WAN port, igb3 is the LAN port.

Code Select Expand


Feb 28 20:14:33 calgary filterlog: 98,,,0,igb2,match,pass,out,4,0x0,,64,15585,0,none,17,udp,492,96.51.y.y,162.212.x.x,500,500,472
Feb 28 20:14:33 calgary filterlog: 92,,,0,igb2,match,pass,out,4,0x0,,64,54613,0,none,17,udp,432,96.51.y.y,162.212.x.x,4500,4500,412
# ESP traffic is listed as outbound from WAN igb2 as expected
Feb 28 20:14:37 calgary filterlog: 100,,,0,igb2,match,pass,out,4,0x0,,64,17677,0,none,50,esp,148,96.51.y.y,162.212.x.x,datalength=128
# suddenly changes to outbound from LAN igb3
Feb 28 20:17:18 calgary filterlog: 92,,,0,igb3,match,pass,out,4,0x0,,64,24955,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
# and then changes to inbound to LAN igb3, resulting in a block
Feb 28 20:17:18 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,27452,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:18 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,4042,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:18 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,17528,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:19 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,10157,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:19 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,14787,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:19 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,25526,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:20 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,13062,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:20 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,11938,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:20 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,23065,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:21 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,37367,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:22 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,57219,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:22 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,45356,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:23 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,7877,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:23 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,492,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:23 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,52354,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:27 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,53851,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:27 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,57452,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:27 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,51372,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:30 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,38156,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:30 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,39704,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:30 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,34262,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:17:36 calgary filterlog: 10,,,0,igb3,match,block,in,4,0x0,,64,760,0,none,50,esp,140,96.51.y.y,162.212.x.x,datalength=120
Feb 28 20:18:04 calgary filterlog: 98,,,0,igb2,match,pass,out,4,0x0,,64,46766,0,none,17,udp,492,96.51.y.y,162.212.x.x,500,500,472


I'm not certain but I think this intermittent packet blocking is dropping my tunnel regularly and making things unusable. Sometimes it will only be up for a couple of minutes, sometimes a couple of hours. Can anyone explain why traffic that is going out the WAN port all of a sudden gets classified as coming in the LAN port?

Complete IPSec log of the session corresponding to the above filter log, from manual start to unexpected drop: https://pastebin.com/ynEw5Q2s

Here are my rules that work.
The 176.16.99.0/24 network is th one i configured in  VPN --> IPsec --> Mobile Clients .

I'm using a site-to-site VPN, so not really the same thing. Also, you shouldn't be leaving your management interfaces wide open for the world to see!

I've done this loads of times on a pfSense without issue, thought I'd give OPNsense a try for a change, and am hitting a brick wall.

I've got an IPSec tunnel set up between my OPNsense router and a Cisco ASA. Tunnel is good, and users behind the router can reach hosts on the remote network without issue. The problem is traffic originating on the router itself, which does not get sent through the tunnel as it should. I've set up the requisite hack of a static route pointing to the LAN interface so the routing is good, but traffic gets dropped by the firewall for some reason. Naturally I have an allow all rule on the IPSec interface.

I've narrowed this down to the firewall because if I disable it with pfctl -d my traffic is sent without issue. Looking at the logs while trying to ping a host on the remote network, I noticed this:

The 96.51.x.x is my local WAN address, and 162.212.x.x is the tunnel endpoint. That traffic definitely should not be getting blocked. There's an automatically generated rule that should pass it:

Code Select Expand


pass out log on igb2 route-to (igb2 96.51.y.y) inet proto esp from any to 162.212.x.x keep state label "IPsec: NOC"
pass in log on igb2 reply-to (igb2 96.51.y.y) inet proto esp from 162.212..x.x to any keep state label "IPsec: NOC"


The fact that it's showing up as coming from the LAN interface is concerning. So I've put in floating rules to allow ESP traffic to and from the remote router but still the traffic originating from the local router does not pass.


Any thoughts on what could be causing this?