Messages

So I've been looking at the /tmp/rules.debug file, and I've noticed this :

- When I leave the gateway unedited (using "dynamic" which seems to resolve to the interface's IP) then the rules do have a proper reply-to generated, but since that IP is the interface itself the packets are just going through the loopback interface instead of vpn

- If I edit the gateway and put another IP in there then policy based routing starts working, but reply-to is not added to the rules anymore so replies are leaving through the wrong interface.

I've tried editing the gateway to get routing to work, then edited the /tmp/rules.debug file to add the missing reply-to bits and re-applied it and that fixes my issue : incoming and outgoing connections are working as expected.
Now obviously that's not practical, I can't be editing the file after each reboot.

Not sure if I'm doing something wrong or if this is a bug, but I might create an issue on github since I don't know what else to do at this point.
Thanks for checking your config though !

I don't have any outbound rules on that interface, so I can't do much there.
I have an inboud rule allowing port 80, on which I've tried both disable reply-to ticked and unticked but same result.

As for outbound NAT yes, but I have to define it manually since it's not automatically created. It should be though, according to the doc any wan interface should have reply-to and outbound nat created automatically but clearly it's not happening.

Defining all of that manually does work for policy based routing (internal connections going out) but not for external connections going in, these get answered on the wrong interface.

EDIT: Oh and I have tried ticking and unticking the "This interface does not require an intermediate system to act as a gateway" box on the interface page and to be honest I have no idea what it changes, everything looks exactly the same either way as far as I can tell

You mean the rule allowing port 80 / 443 inound ?
On the interface's page, not the generic openvpn one. I've tried with or without reply-to enabled and the result is the same : packets come into the vpn interface, but responses leave through the WAN interface (with the VPN interface's IP as the source, somehow).
I think the issue is that reply-to is missing on the vpn interface, so it leaves back through the default WAN interface.

Note that policy based routing does work, I'm able to route stuff through the VPN just fine as long as the connections originates from my LAN. Connections from outside however leave through the WAN, whatever I do.

Hi,

I have a routing issue (in another post) but I suspect the real issue is my openvpn client config.

I have an OpenVPN client configured in tun mode, udp, going through the WAN interface. My default gateway is the WAN interface, the vpn client is only there for some policy based routing.
What I've noticed is that the system doesn't seem to be considering the vpn interface as a WAN, so it's not generating outbound NAT rules and it's doesn't seem to be using reply-to (which is my real issue) on it.

When the connection gets established, a public IP is properly assigned to the interface, and a Gateway is created.
Below the two IPv4 black boxes (IP and Gateway) are covering the same exact IP.



That gateway has "dynamic" as the IP address, since I've ticked the "This interface does not require an intermediate system to act as a gateway" box in the interface config :



However in the Gateway "single" menu, the IP for the gateway is the interface's IP itself (instead of dynamic, seen when editing the gateway), hiding the IP since it's public :




There's also a route added by something to route the interface's IP to the loopback interface (the red square is the interface's IP, the black squares are just routes added by openvpn for the subnet and the first IP of the bloc) :



The result is that when trying to use the VPN, packets are routed through the loopback interface back at opnsense itself, instead of going through the VPN. So if I try to query any website for example, I'm getting my own HAProxy back since it's listening on ports 80 / 443 of the router.

One way to work around this I've found is to edit the gateway and use any other IP as a gateway, since openvpn doesn't actually require a gateway ip any value works there as long as it's not the interface's own IP (which seems to be the default value chosen when using dynamic).
That allows policy based routing to work, but that's obviously not a good way and still doesn't make it generate proper outbound NAT and reply-to rules so incoming connections aren't working.

Any ideas what I might be doing wrong ? I've been struggling with this for almost a week now.
Thanks

So one thing I've noticed while looking into this some more is that no outbound rules are actually being generated.
I think the issue might be that the VPN is somehow misconfigured : I ticked "Dynamic gateway policy" but with or without that setting the Gateway it generates is wrong. When editing the gateway the IP field says "dynamic" but when looking at the status it's using the vpn's interface IP.
And when using it that's confirmed : any traffic routed "through" the VPN ends up hitting the router itself instead of going through the tunnel. As a workaround I've changed the gateway IP from "dynamic" to some random IP in the bloc, which works fine, but it really shouldn't have an IP at all.

Could this be why it's not working right ? I'm guessing opnsense isn't really considering my vpn interface as a wan because it doesn't really have a gateway associated with it, just a dirty hack, so it gets confused.

It wasn't, tried turning it on and re-saving and applying the port forward rule but no change, it's still going back through the wan

Hi opnsense forums,

I have an OpenVPN client connection on my router that I use to get a fixed public IP, as my ISP sadly does some horrible stuff on the WAN interface. So my ovpnc2 interface has a proper dedicated publicly routed IP.

I have a mail server machine I've been trying to setup in the LAN, and I've created a floating firewall rule saying that anything coming from that machine on the LAN interfaces should use the VPN Gatway, which works fine. When I do a "curl ifconfig.me" on that email machine for example I do get the public IP from the vpn interface.

For the other way around I have a port redirect setup to forward tcp port 25 on the vpn interface to that machine on the lan.
Using tcpdump and packet captures on both the machine and the router I can see that incoming connections on port 25 are indeed sent to the mail server, and it's responding fine. But I can see on the router that the paquets are going out the WAN interface, not the VPN interface. Even stranger they are using the VPN interface's IP as a source, on the WAN interface, which of course does not work.

Any idea what I could be missing ? My default gateway is the WAN (but overriding it with floating rules works), my NAT is configured as hybrid and I did setup a rule for the vpn interface (and it seems to be valid since outgoing connections through the vpn are working) and I can't find any other rule that would explain it responding through the wrong interface.

Thanks

Hi,

Is there any way, either through API or SSH or anything else, to have an external system enable or disable an existing firewall rule ?
I have a rule to send my TV's traffic through a VPN (for geo locked content) and I'd like to be able to quickly toggle it on or off from home assistant, I was thinking of just writing a script but it looks like the API doesn't expose anything outside of aliases for the firewall.

Is there any other way to get it to work ?

Thank you

As discussed on IRC, that patch does solve my problem :)
Thanks

Discussing this on IRC and I tried the f25d8b7 patch, not better. Sadly, it must be a different bug.

I checked and the other Opnsense I used to test is a 17.1, so the bug seems to only be in 17.7. I might revert

Hi,

I used to run 17-rc1 until a few days ago, when I upgraded all the way up to 17.7.
The only problem I seem to have with this is my OpenVPN client, which is not working great anymore.

Basically it still connects, and incoming packets work fine (I can ping from outside trough the VPN), but not the other way around.
ping -S <VPN IP> 8.8.8.8 with a tcpdump running on the vpn interface and another tcpdump running on the WAN interface shows that the packets are actually trying to come out of the WAN interface with the VPN IP, which makes no sense.
The same test on a different opensense installed recently shows packets coming out of the VPN interface, as expected.

So what could cause ping -S to send packets out of the wrong interface ?
I've tried deleting and re-creating the VPN interface and the firewall rules, no luck. I've even tried adding a firewall rule on the VPN interface to force the VPN Gateway, didn't change anything. I don't have any floating rule or anything exotic except a bit of QoS on the WAN, but I don't expect that to be responsible.

For future reference, in case any one else is trying to do something similar, here is my current config.

Queues :


Rules :


And I haven't touched the pipes (just tweaked the speeds) since the screen in the first post.
With that I have SSH as highest priority, then my Kodi box, then everything else. Works well, a lot better than last time I tried it with pfSense !

Ah, I didn't realise you answered it there, I actually made the change by hand.
In any case as I said on IRC it does seem to fix the problem, so thanks a lot !

Quite impressed that it was fixed in such a short time I must say :)
Traffic shaping now works exactly like I wanted.

Thanks to people on IRC I did get that working pretty well.
Now I'm trying to add another rule to get Kodi (which is on a dedicated box) to get a priority between ssh (at 1oo) and everything else (at 1).

Somehow whatever I try I can't get everything to match the rule. I can see using the status menu in traffic shaper that my ACK rule and my Down rule do get matched, but most of the traffic still ends up in my everything catch all rule. I tried matching using the local IP of the kodi box, I tried matching using the remote IP of the server it's connecting to, no luck.
I even tried, to check, just running a wget from that server on my laptop and doing a tcpdump : it is responding with the correct IP, the one I've configured in the rule. I really don't understand how some of the traffic can match but not the rest.

So that brings me to my current question : is there a way to see what's in each queue ?
I'd like to see exactly what are the packets getting sent to my everything queue, figure out why they don't match.
I've tried I think every menu from the web interface but I assume there must be a command in ssh to display that ?
I'd basically just need to know the source / destination of the packets, that'd be enough.

Thanks !

Hi,

I'm trying to connect to a couple of routers using IPsec.
For work, I have control over the other router so I just configured a site to site tunnel and it works fine.
But I have another one I want to connect to over which I have no control. (I do know we are only two using it so maybe I could talk to the other person and change it, but I'd rather not, it's been working fine for years)

Here is the config I'm supposed to be using :

config setup
       plutostart=no

conn %default
       ikelifetime=60m
       keylife=20m
       rekeymargin=3m
       keyingtries=1
       keyexchange=ikev2

conn grifon
       leftid=$utilisateur@<other side>
       leftfirewall=yes
       leftauth=eap-ttls
       right=<other side>
       rightid="C=FR, ...."
       rightsendcert=never
       rightauth=eap
       type=transport
       auto=start
       closeaction=restart

I've been trying to figure out what to put in the web interface to arrive at a config file looking vaguely like this, and I'm starting to think there's just no way.
As for the password, it's supposed to be put in the secrets file in this form :

$utilisateur@<other side> : EAP "motdepasseutilisateur"

Do you have any tips on how I could connect to this ?
I'm supposed to be adding L2TP after that, too.

Thanks