Messages

[Restarting dpinger does not solve the situation.]

On 26.7.2_2 DHCP6 interface outage results in dpinger using ULA source address after outage and restored connection. I am not sure if this started with 26.7 but it's the first time I observed this using 26.7. I can also reproduce this by disconnecting the router manually.

Before outage dpinger works as expected and uses GUA as source address for pinging and gets normal responses.

After a longer (don't know the exact time, several minutes to an hour) outage connection is restored but dpinger thinks the connection is down because it does not get replies. The reason is that ping source address is changed to ULA and the router does not accept that and no pinging happens.


Dpinger runs with right GUA source address in the -B parameter:
root@opns1:~ # ps axuww | grep INTERNET_DHCP6
root   51553   0.0  0.1  14716   2812  -  Is   07:12      0:00.02 /usr/local/bin/dpinger -f -S -r 0 -i INTERNET_DHCP6 -B 2a0d:a:b:c:d:e:f:2d93 -p /var/run/dpinger_INTERNET_DHCP6.pid -u /var/run/dpinger_INTERNET_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888

Ping packets have anyway ULA as their source:
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:53.428522 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14719, length 9
07:02:53.429161 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:02:54.428627 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14720, length 9
07:02:54.429308 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)


Manually pinging another destination with same GUA as source works:

root@opns1:~ # ping6 -I vlan0.9 -S 2a0d:a:b:c:d:e:f:2d93 2606:4700:4700::1001
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:57.844648 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 0, length 16
07:02:57.877492 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 0, length 16
07:02:58.846441 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 1, length 16
07:02:58.874800 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 1, length 16

root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
   route to: 2001:4860:4860::8888
destination: 2001:4860:4860::8888
    gateway: fe80::bb:ccff:fedd:2e0%vlan0.9
        fib: 0
  interface: vlan0.9
      flags: <UP,GATEWAY,HOST,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
   description: Internet (opt22)
   options=4000000<MEXTPG>
   ether 00:aa:bb:cc:2d:93
   inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
   inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
   inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
   inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
   inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
   groups: vlan
   carp: MASTER vhid 187 advbase 1 advskew 1
         peer 224.0.0.18 peer6 ff02::12
   vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
   media: Ethernet autoselect
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>


I have IPv4 static and carp address on the same interface as DHCP6. Does that mess things up? This interface vlan0.9/opt22 is also the secondary IPv6 gateway if that gives any hint where this problem might originate from.

Restarting dpinger does not solve the situation.

root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:10:25.486875 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 11, length 9
07:10:25.487554 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:10:26.486944 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 12, length 9
07:10:26.487636 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)


Reconfiguring the interface and restarting dpinger:

root@opns1:~ # configctl interface reconfigure opt22
OK
root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.

Works and dpinger starts to use correct GUA source address 2a0d:a:b:c:d:e:f:2d93 again.

The only change I can see is the order of inet6 addresses returned by ifconfig and route information for the dpinger destination.

root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
   description: Internet (opt22)
   options=4000000<MEXTPG>
   ether 00:aa:bb:cc:2d:93
   inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
   inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
   inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
   inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
   inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
   groups: vlan
   carp: MASTER vhid 187 advbase 1 advskew 1
         peer 224.0.0.18 peer6 ff02::12
   vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
   media: Ethernet autoselect
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
   route to: 2001:4860:4860::8888
destination: ::
       mask: ::
    gateway: fde7:a:b:c:d:e:f:11 (this is the primary default gw for IPv6)
        fib: 0
  interface: vlan0.11
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

Solved. This was probably an upgrade quirk. Solved by doing a fresh bootstrap install. Source NAT works as expected with same config as in 26.1.

[On 26.1. I can do Source NAT]

Migrated to Source NAT already in 26.1. and had this configuration working. Something seems to have changed in 26.7.

I have a site with three uplink internet gateways. I run three instances of wireguard tunnels one through each gateway to one and same wireguard server. All three tunnels use different destination port. I have floating rules in place to select specific gateway based on the destination port.

Floating rules, the new ones, legacy rules are removed:

• Source=This firewall, Destination=WGserver, Port=GW1port, Gateway=GW1
• Source=This firewall, Destination=WGserver, Port=GW2port, Gateway=GW2
• Source=This firewall, Destination=WGserver, Port=GW3port, Gateway=GW3

All three gateways are on separate interfaces and IPv4 networks. Source NAT Mode=Manual Source NAT rule generation.

Tunnel 1 through primary connection (Gateway1) works as expected. Wireguard traffic source address is chosen as Interface1 address.

Tunnel 2 also works and traffic is routed through Gateway2 as expected. However, the source address for the tunnel2 traffic is still Interface1 address. This works as Gateway2 router is in my control and I can make it route Interface1/address originated packets back correctly. No NATting is needed.

Tunnel 3 does not work. I cannot control Gateway3 router and it rejects packets having Interface1 address as their source. And this is something I cannot change so I have to use Interface3 addresses.

On 26.1. I can do Source NAT

• Interface=Interface1, DAddr=WGserver, DPort=GW3port, Translate Source IP=Interface3 address typed in as fixed IP address (not empty field=>Interface address)
  
• This configuration is slightly confusing but it works. I assume Source NAT configuration applies before firewall rules gateway selection and that's why I have to use Interface1 although packets leave from Interface3?

On 26.7.1_1 Same configuration does not work in the same way as in 26.1.

• With the same working configuration used in 26.1. Tunnel3 traffic source address is indeed changed to Interface3 address but Tunnel3 traffic is sent to Gateway1 through Interface1 instead of Gateway3 through Interface3. It looks like the floating rules don't apply anymore.
• Without Source NAT configuration in place, Tunnel3 traffic is catched by floating firewall rule and the right Gateway3 is selected. Only the source address is from Interface1 and those packets are rejected by Gateway3.
  
• I have tried multiple configurations using Interface1 and Interface3 in the Source NAT but I have not found combination that would do both Source NAT and Gateway3 selection.
• Floating firewall rules are not touched.

Other Source NAT rules seem to work as they did in 26.1.

Any tips if this could be because of misconfiguration, expected change or corrected bug? Or is there something else I could try to force Source NAT address on the packets leaving from Interface3 to Gateway3?

Hello, I can also confirm your findings that this setting behavior is inverted after 25.1.6 update.