Messages

I figured it out. I was doing my testing locally from the router itself doing stuff like curl --interface <iface> <url>. This didn't work as there is no IN step for packages generated by the command, and it is in that stage that the policy routing is applied.

It all works with traffic generated from outside the router.

I am trying to configure an interface (let's call it vpnLAN) so traffic originating from its network is routed to a VPN gateway (VPNLAN_GW). I did the following:

• added an "allow vpnLAN to any rule" under Firewall > Rules > vpnLAN
• added a floating rule so that traffic originating from vpnLAN net with destination ! talpaWAN net has gateway VPNWAN_GW
• added an outbound NAT rule so that traffic on the vpnWAN interface (the VPN interface) with source vpnLAN net has NAT address vpnWAN address
  

However, this doesn't work. I inspected the logs and it looks like the NAT rule is never applied. This may be because the NAT rules are applied before the other rules, which means that when NAT happens the policy-based routing didn't happen yet, which means the gw hasn't been set up to VPNWAN_GW and the NAT rule doesn't apply.

I am surprised as this is roughly the setup described here: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html.

What am I doing wrong? Thanks!

Hi, I have a multi-wan setup (a "normal" WAN interface and a VPN), and two LAN interfaces configured with two separate subnets (say 192.168.1.1/24 and .2/24), one reaching the internet via the WAN interface, the other reaching the internet via VPN, using policy based routing. I can test this works by doing, for example:

Code Select Expand

curl --interface <iface> ifconfig.co

My question now is: how does OPNsense chose which source address to use by default for traffic originating from the router? This matters as the gateway will be different, depending on the source ip address.

Thanks!

Thanks again. I didn't directly ask, maybe next week I'll drop them an email.

Thanks! But in my understanding the warning I cited in my original post is about not setting up a 2.5G/5G link in one of the DEC750 SFP+ ports, and a 10G link on the other SFP+ port at the same time. So I am not speaking of links ends, but of module usage on the same device.

I'll rephrase my question. On the DEC750, can I use a SFP+ module on one port, and a SFP (= 1Gbps) module on the other port?

Hello, the DEC750 product description (https://shop.opnsense.com/product/dec750-opnsense-desktop-security-appliance/) has this warning:

When using SFP+Modules, do not mix 2.5/5Gbps and 10Gbps link-speed as the hardware does not support mixing these due to different frequencies.

However it is not clear to me if I can mix 2.5/5Gbps and 1Gbps link speeds on two SFP+ modules. I know I could just use one of the RJ45 Ethernet ports for the 1Gbps link, but I like the idea of just bumping the link speed if I end up getting better hardware.

Thanks!

I want to setup a cronjob that changes the WiFi password on a daily basis (the password will be shown on an external display).

I can put together a script that changes the relevant hostapd.conf, but I'm wondering: is there a better way to do it in OPNsense? Something like a higher level CLI?

Same for restarting the network interface for which the password has been modified: what's the OPNsense way to do it from a script?

That's exactly the case, but I asked for the additional public and static IPv4 address I mention. With that address I can host services and do whatever I want, and it works. I'd just like to generate outgoing packets with this IP as the source IP, without changing it afterwards with a NAT rule.

My ISP's DHCP assigns me a private, dynamic IP address (10.151.105.106/26), and in this subnet I have my default gateway (10.151.105.65). Then I have a static, public IP address assigned, let's say 2.234.35.29/32. I can't connect to the Internet using my private ip address (get an ISP redirection to an error page), but if my outgoing packets have the src address set to 2.234.35.29, the gateway accepts them and everything works. I set 2.234.35.29 as "Alias IPv4 address" for the Ethernet interface, so the situation is:

Code Select Expand


em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
        ether d0:d4:12:xx:xx:xx
        hwaddr 00:00:24:xx:xx:xx
        inet6 fe80::xxxx:xxxx:xxxx:xxxx%em0 prefixlen 64 scopeid 0x1
        inet 10.151.105.106 netmask 0xffffffc0 broadcast 10.151.105.127     # dhcp assigned
        inet 2.234.35.29 netmask 0xffffffff broadcast 2.234.35.29           # alias
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active


The point is, OPNsense (FreeBSD) chooses 10.151.105.106 as source address for the locally generated outgoing packets, as this is address is in the same subnet of the default gateway, I guess. I want it to set it to generate packets with src=2.234.35.29 by default. This seems to be easily doable in Linux [1] (route ... src ...), but I can't find an equivalent in OPNsense's interface, and apparently the src option is not available in FreeBSD's route command.

I dug deep into the FreeBSD forum, and other people asked similar questions in the past. They were pointed towards policy based routing or to setfib. I read about policy based routing, but it seems to me that it is helpful in setting for example the next hop of a package (ipfw add fwd ..., that is source based routing), but I couldn't find a way to change the default source address. On the other side, setfib seems conceived to set routing tables per-process, not system wide.

Again: I don't want to do source based routing, but somehow the contrary: route based source selection.

Changing the src address with a rule under Firewall→NAT→Outbound does the job, but I don't think it's the best thing to do.
I would like the packets to be generated with the correct address in the first place.

What could I try?

I'm running OPNsense 18.1.2.

Thank you.

[1] https://manpages.debian.org/stretch/iproute2/ip-route.8.en.html