Messages

1

23.7 Legacy Series / Postfix ignoring one of the manually applied changes

« on: August 28, 2023, 09:51:30 pm »

Hi,

I need to set local_header_rewrite_clients = permit_mynetworks in postfix configuration, so I added it to  /usr/local/etc/postfix/main.cf accordingly, restart the service, yet the old, default permit_inet_interfaces value persists, confirmed by postconf -d , as well as the actual behavior of postfix in that aspect.

For the record, I applied other options the same way and they work just fine, so postfix doesn't like this particular one for some reason. I searched the Internet and couldn't find anything specific to postfix itself that would make it ignore that switch, hence I wonder if this is some OPNSense or FreeBSD peculiarity that I am missing?

Any ideas?

2

Development and Code Review / Re: API Wireguard "result": "failed"

« on: November 22, 2022, 12:20:38 am »

Having same issue trying to toggle a firewall rule:

Code: [Select]

curl -k -u "user":"pass" "https://opnsense/api/firewall/filter/toggleRule/702cdc85-cf43-437a-9882-4beba77fb35c/0" -X POST -d ""
{"result":"failed"}%
This is same as in this example: https://docs.opnsense.org/development/api/plugins/firewall.html

The uuid is a correct one, I can do:

Code: [Select]

url -k -u key:pass "https:/opnsense/api/firewall/filter/getRule?uuid=702cdc85-cf43-437a-9882-4beba77fb35c"
and obtain a complete JSON with details.

Also getting same error with a simpler:

Code: [Select]

curl -k -u key:pass "https://opnsense/api/firewall/filter/toggleRule/702cdc85-cf43-437a-9882-4beba77fb35c/1"
How does one actually obtain some more meaningful reason for an error?

EDIT: my issue was due to the Firewall Plugin API only supporting rules that were added using its own UI; see https://github.com/opnsense/docs/pull/437

3

General Discussion / Re: OPN in a Proxmox VM, trying to spoof VM NIC to transparently relay to host NIC

« on: August 30, 2022, 10:22:20 pm »

(nvm)

4

General Discussion / Re: OPN in a Proxmox VM, trying to spoof VM NIC to transparently relay to host NIC

« on: August 17, 2022, 07:56:20 pm »

why should it forward these frames

But also setting the interface/bridge to promiscuous should lift any such restrictions, yet that didn't help, either.

5

General Discussion / Re: OPN in a Proxmox VM, trying to spoof VM NIC to transparently relay to host NIC

« on: August 17, 2022, 07:43:12 pm »

Well, that makes sense, but I won't be able to change host's MAC address, as this is not something I can pull off with Azure.

6

General Discussion / Re: OPN in a Proxmox VM, trying to spoof VM NIC to transparently relay to host NIC

« on: August 16, 2022, 06:59:46 pm »

No experience with Proxmox, but my guess would be: Since the DHCP reply is addressed to the eth0 MAC address, the host claims it for itself and doesn't forward it to the VirtIO NIC. Changing the eth0 MAC address to something random might work.

Thanks, but rather unlikely: eth0 on host is configured to 'manual', that is not to use DHCP on that interface. And it doesn't, because ISP keeps sending DHCPOFFERs and they do not get picked up — the eth0 on host is left untouched.

7

General Discussion / OPN in a Proxmox VM, trying to spoof VM NIC to transparently relay to host NIC

« on: August 15, 2022, 06:36:07 pm »

(FYI, this is a cross-post from Proxmox forums, where I got no response: https://forum.proxmox.com/threads/trying-to-spoof-guest-nic-to-transparently-relay-to-host-nic.113600/#post-490741)

I am trying to set up OPNSense inside Proxmox. Unfortunately I cannot pass the interface as is, due to lack of IOMMU support, as I am running this in a nested Azure VM, so I need to get by using bridges.

The host configuration is:
– eth0
– vmbr0 with eth0 assigned to it

Code: [Select]

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
The guest configuration is:
– VirtIO NIC attached to vmbr0, with MAC overridden using same address as the eth0
– Firewall: NO
– MAC Filter: NO

Running dhclient on eth0 or vmbr0 correctly discovers and assigns an IP address.

Now, I am trying to get the OPNSense in a VM to get that IP address instead and to relay its traffic via the vmbr0 transparently outside of the host. I have done something very similar previously between OpenWRT running in a VM and another VM, using OpenWRT's "trivial relay" (kmod-trelay, see https://forum.openwrt.org/t/howto-kmod-trelay/49610/2, also https://github.com/openwrt/openwrt/commit/c3bba7f8c61ee98265bcffef8ee86e22aa89bbe9), and despite that this particular case is much simpler, I can't get the VM to communicate with the ISP properly. I tried simply by spoofing the eth0's MAC address by setting the OPNSense VM's interface to it, but that's not enough.

I also checked the traffic on both ends using tcpdump, and, interestingly, vmbr0 does see the DHCP requests coming from the VM, and the ISP does respond, but that response never reaches the VM, nor the tap interface corresponding to the VM that Proxmox assigned to the bridge.

What am I missing here?

8

Virtual private networks / Re: Routing Virtual IP traffic over VPN

« on: April 15, 2022, 06:13:56 pm »

Does anyone have any idea regarding this? A definite answer whether or not it is possible to selectively route specific *service's* traffic (which is bound to a Virtual IP) would be appreciated.

9

Virtual private networks / Routing Virtual IP traffic over VPN

« on: March 16, 2022, 11:33:58 pm »

I managed to set up selective routing via WG VPN for LAN clients (https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html). Now I also want to route traffic originating from a service bound to a Virtual IP (10.0.0.91) configured on the LAN interface, i.e. from the firewall appliance itself.

I can see that the service running is successfully bound to the Virtual IP, looking at the tcpdump -ni vtnet0 output:

Code: [Select]

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:31:34.414408 ARP, Request who-has 10.0.0.91 tell 10.0.0.100, length 46
23:31:34.414456 ARP, Reply 10.0.0.91 is-at 62:15:db:f6:60:1b, length 28
23:31:34.418506 IP 10.0.0.100.51915 > 10.0.0.91.80: Flags [S], seq 120292338, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1261429721 ecr 0,sackOK,eol], length 0

However, my understanding is that these packets internally do not pass the LAN interface table, so the selective routing rule I have set up for LAN hosts won't do. I tried searching for a similar issue solved here, but no luck.

Any idea how to proceed here? I will appreciate help.

EDIT: Seems related: https://forum.opnsense.org/index.php?topic=16252.0

EDIT: OK, seems this is the culprit: https://forum.opnsense.org/index.php?topic=23399.msg111294#msg111294

However, disabling the forced gateway does *not* create a set of manual rules here. Investigating further.

EDIT: OK, I re-added the manual floating rule to "let out anything from firewall host itself (force gw)", so that I can add another rule above it, except nothing I do has any effect. I am clueless.

10

Virtual private networks / Re: Traffic routed arbitrarily over the Wireguad Interface despite disabled WG gw

« on: March 16, 2022, 08:28:55 pm »

Snap I knew it must have been something stupid, spent too much time on this today. Thanks, works as expected now.

11

Virtual private networks / Re: Traffic routed arbitrarily over the Wireguad Interface despite disabled WG gw

« on: March 16, 2022, 07:45:21 pm »

Firewall stats show that neither of the Firewall rules are being evaluated.

12

Tutorials and FAQs / Re: [Tutorial] Selective Routing to Private-VPN (via Wireguard)

« on: March 16, 2022, 07:19:38 pm »

In "Create a Gateway" section, step "4. Enter the Tunnel Address from your Local Wireguard Configuration" is inconsistent with https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-6-create-a-gateway.

13

Virtual private networks / Re: Traffic routed arbitrarily over the Wireguad Interface despite disabled WG gw

« on: March 16, 2022, 04:52:17 pm »

Sorry for the delay in replying.

So what was causing the routing issue with LAN clients was the fact that I did not have the "Disable routes" checked in Local Endpoint configuration. I was migrating my config step-by-step from pfSense, where this isn't an option, hence the omission. Once disabled, the WG interface is no longer messing up the regular LAN-WAN traffic. My apologies for allowing myself show my frustration.

However, having followed the https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html , I still can't get selective routing to work over WG. I had designated one of the hosts in the LAN to have all its traffic routed via WG, to no avail – the traffic is routed via WAN.

Requested screenshots: https://imgur.com/a/YgzypHL
Note that there aren't any rules in "WG_BULLET" WG interface table nor "WireGuard (Group)"

The setup is:
- WG DNS 10.100.0.1
- WG client address 10.100.1.11/32

From my debugging, it seems that the issue is related to Firewall LAN rules, specifically.

For example, despite the LAN rule being present for the 10.0.0.100 client traffic to 10.100.0.1 (the WG DNS) be forwarded via the WG_BULLIT_GW, issuing dig @10.100.0.1 google.com from the 10.0.0.100 yeilds connection timeout. However, if I add an explicit System Route (System -> Routes -> Configuration) to route 10.100.0.1/32 via the WG_BULLIT_GW, DNS queries work right away, and I can see the relevant traffic in tcpdump -ni wg1 output:

Code: [Select]

16:49:28.193324 IP 10.100.1.11.20462 > 10.100.0.1.53: 12284+ [1au] A? google.com. (39)

14

22.1 Legacy Series / Re: OPNSense on Azure messing up routes?

« on: March 10, 2022, 10:12:43 am »

I bootstrapped myself, using https://github.com/dmauser/opnazure

Not sure what you mean by assignments, though?

15

22.1 Legacy Series / OPNSense on Azure messing up routes?

« on: March 10, 2022, 12:40:43 am »

I migrated to OPNSense from pfSense on my Azure (self-provisioned) appliance and everything is mostly fine, except one issue I have with the routes it it is setting up using DHCP, which render the 168.63.129.16 (https://docs.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16) unusable.

Have a look at the dump first:

Code: [Select]

root@gw:~ # netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.32.0.1         UGS         hn0
10.0.0.0/22        87.99.46.47        US          hn0
10.1.0.0/23        link#6             U           hn1
10.1.0.4           link#6             UHS         lo0
127.0.0.1          link#1             UH          lo0
168.63.129.16      link#6             UHS         hn1
169.254.169.254    172.32.0.1         UGHS        hn0
172.32.0.0/24      link#5             U           hn0
172.32.0.7         link#5             UHS         lo0

root@gw:~ # ifconfig
hn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
ether 00:22:48:4f:b5:c7
inet 172.32.0.7 netmask 0xffffff00 broadcast 172.32.0.255
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
hn1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
ether 00:22:48:4f:bd:3f
inet 10.1.0.4 netmask 0xfffffe00 broadcast 10.1.1.255
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Now, compare it to the output from the old pfSense appliance:

Code: [Select]

root@gw:~ # netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.32.0.1         UGS         hn0
10.1.0.0/23        link#6             U           hn1
10.1.0.14          link#6             UHS         lo0
127.0.0.1          link#2             UH          lo0
168.63.129.16      00:0d:3a:7d:83:47  UHS         hn0
168.63.129.16/32   172.32.0.1         UGS         hn0
169.254.169.254/32 172.32.0.1         UGS         hn0
172.32.0.0/24      link#5             U           hn0
172.32.0.4         link#5             UHS         lo0



root@gw:~ # ifconfig
hn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=48001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,LINKSTATE,TXCSUM_IPV6>
ether 00:0d:3a:7d:83:47
inet 172.32.0.4 netmask 0xffffff00 broadcast 172.32.0.255
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
hn1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=48001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,LINKSTATE,TXCSUM_IPV6>
ether 00:0d:3a:01:7f:5f
inet 10.1.0.14 netmask 0xfffffe00 broadcast 10.1.1.255
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>


Notice that the pfSense routes both 168.63.129.16  and 168.63.129.16/32 using the WAN interface, whereas OPNSense somehow assigns 168.63.129.16 to LAN. Removing the latter rule manually restores the communication back.

What's happening here? Any ideas?

This is fairly crucial, since 168.63.129.16 handles communication with the Agent, including backing up.