Topics

1

23.1 Legacy Series / 23.1.9, OpenVPN clients dual IPv4 IPv6, IPv4 working, IPv6 isn't

« on: June 13, 2023, 10:38:56 pm »

Hi,

I've set up an openvpn server, and it dishes out both IPv4 and IPv6 addresses. In the Advanced section of the server I've added 'push "redirect-gateway ipv6"', and so far all seems fine. Clients connect, they get both IPv4 and IPv6 addresses assigned, and on IPv4 things are all good. I set up a NAT to the WAN, they can browse the Internet, and connect to both the LAN and DMZ networks internally.
On IPv6: not so much. I can see traffic coming in from the clients using tcpdump, but it's dropped on the firewall without a trace in the logs.
The Firewall rule under OpenVPN has 1 simple rule, to allow everything that comes in from the clients: (IPv4+6, pass). Logging is enabled, and I can see log-entries for IPv4 traffic, just nothing for IPv6.

Where oh where does one go to analyse further?

Thanks for any help in advance.

Ferry.

PS. The networks are all dual stack, including the WAN connection.

2

20.1 Legacy Series / GRE tunnel (over WireGuard) doesn't come up after reboot

« on: March 09, 2020, 12:51:01 am »

Hi,

I run a couple of GRE tunnels over WireGuard VPNs. Works fine, except after a reboot. When I look at one of the tunnels after a boot, it looks like this:

root@OPNsense:~ # ifconfig gre1
gre1: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1396
        options=80000<LINKSTATE>
        inet 10.1.11.6 --> 10.1.11.5 netmask 0xfffffffc
        inet6 fe80::20c:29ff:fea3:3bc8%gre1 prefixlen 64 tentative scopeid 0xa
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: gre

i.e. Link not set up. When, in the OPNsense interface, I go to this GRE tunnel, edit it, hit Save and Apply (without changing any settings), things start working and ifconfig shows me the below:

root@OPNsense:~ # ifconfig gre1
gre1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1396
        options=80000<LINKSTATE>
        tunnel inet 10.1.9.2 --> 10.1.9.1
        inet 10.1.11.6 --> 10.1.11.5 netmask 0xfffffffc
        inet6 fe80::20c:29ff:fea3:3bc8%gre1 prefixlen 64 scopeid 0xa
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: gre

I'm not entirely sure what is happening here. Could it be a timing issue, in that the GRE tunnel can't be set up until routing entries exist after the WireGuard tunnel has negotiated? If so, is there any way I can trigger things after WireGuard has established its link?

Chees,
Ferry.

PS, further to this, some dmesg output from the boot:

Code: [Select]

Trying to mount root from ufs:/dev/gpt/rootfs [rw,noatime]...
random: unblocking device.
VMware memory control driver initialized
aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard
em2: promiscuous mode enabled
carp: 6@em2: INIT -> BACKUP (initialization complete)
em3: promiscuous mode enabled
carp: 7@em3: INIT -> BACKUP (initialization complete)
em1: promiscuous mode enabled
carp: 5@em1: INIT -> BACKUP (initialization complete)
ifa_maintain_loopback_route: deletion failed for interface em1: 3
ifa_maintain_loopback_route: deletion failed for interface em1: 3
ifa_maintain_loopback_route: deletion failed for interface em1: 3
carp: 5@em1: BACKUP -> INIT (hardware interface up)
carp: 5@em1: INIT -> BACKUP (initialization complete)
ifa_maintain_loopback_route: deletion failed for interface em2: 3
ifa_maintain_loopback_route: deletion failed for interface em2: 3
ifa_maintain_loopback_route: deletion failed for interface em2: 3
carp: 6@em2: BACKUP -> INIT (hardware interface up)
carp: 6@em2: INIT -> BACKUP (initialization complete)
ifa_maintain_loopback_route: deletion failed for interface em3: 3
ifa_maintain_loopback_route: deletion failed for interface em3: 3
ifa_maintain_loopback_route: deletion failed for interface em3: 3
carp: 7@em3: BACKUP -> INIT (hardware interface up)
carp: 7@em3: INIT -> BACKUP (initialization complete)
gre0: link state changed to DOWN
gre1: link state changed to DOWN
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
tun0: link state changed to UP
tun0: changing name to 'wg0'
tun1: link state changed to UP
tun1: changing name to 'wg1'
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
carp: 7@em3: BACKUP -> MASTER (preempting a slower master)
carp: 6@em2: BACKUP -> MASTER (preempting a slower master)
carp: 5@em1: BACKUP -> MASTER (preempting a slower master)
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabledShowing both gre0 and gre1 being down.

Then, when I edit, save and apply both the gre tunnels, the following appears:

Code: [Select]

gre0: link state changed to DOWN
gre0: link state changed to UP
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
gre1: link state changed to DOWN
gre1: link state changed to UP
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled

3

20.1 Legacy Series / Return traffic for VPN going out over default gw instead of the VPN.

« on: March 05, 2020, 04:31:43 pm »

           |           _____________________        _______
           |__________/  GRE over WireGuard \______/ Linux \
        ___|____      \_____________________/      \_______/
       /  WAN   \
       \________/
           |
           |
        ________
       /  OPN   \
       \________/
           |
           |
        ________
       /  LAN   \
       \________/



Hi,

I'm not sure if this can be done or not. I'm currently running a pfSense firewall with an OpenVPN tunnel to a remote Linux server. When a connection comes in on the remote server's IP on say port 443, I do a NAT to direct the connection to a server on 'LAN'. The SYN packet comes in over the OpenVPN tunnel to the pfSense, the pfSense allows it through to the webserver, the webserver responds, and the SYNACK goes back over the OpenVPN tunnel to the remote server and things just work.
For performance considerations I want to start using WireGuard, and for that reason I'm setting up OPNsense and say goodbye to pfSense. I've set up the above. I can ping the WireGuard endpoint on the far side, and because I'll be routing from anywhere on the planet over this, I've set up a GRE tunnel on top of the VPN. And it almost works... Kinda.
Pinging from the local interfaces across the WireGuard and GRE all works, no issues there. However, when a connection comes in from a far-flung machine, the NAT'ed packet reaches the OPNsense on the GRE tunnel, who forwards it to the webserver, but then the problems begin: the return packet, when it reaches the OPNsense, doesn't go out over the GRE tunnel but instead goes to the default gw as per the routing table.

Is there any way to make these connections 'stick' to the incoming interface, in this case the GRE tunnel?

Regards,
Ferry van Aesch