Fritzbox (IP-Client mode) SIP + NAT + dynamic IP Change

[schnipp]

Hi all,

I have problems with the builtin SIP client of my Fritzbox in conjunction with dynamic IP changes triggered by my ISP after 24 hrs. There are already a lot of similar discussions in this forum, but not covering all aspects. The Fritzbox works in IP client mode an gets a private IP address from the Opnsense which itself controls the PPPoE connection to the ISP.

In IP client mode the Fritzbox behind the firewall is not aware of upcoming IP changes. After the latter has occured no incoming SIP connections are possible anymore. This is reasonable because the ISP's SIP registrar knows only the previously registered IP address which is now outdated.

Normally the SIP clients (Fritzbox) must perform a new registration to the SIP registrar. Unfortunately, this does not happen due to the missing information regarding IP address change. By the way the Fritzbox does not allow the to manually the registration expiration time. The siproxd in proxy mode is also no solution.

Has anybody an idea how to solve this issue?

[schnipp]

I did some more investigation and tracked this issue down. The Fritzbox behaves correct and tries to initiate a new SIP registration to the registrar after the public IP has changed. Wireshark showed up a lot of SIP registration requests sent by the Fritzbox which are not answered by the registrar.

A closer look to the packet capture file of the WAN interface revealed multiple source IP addresses used as sender address of overall sent packets. I identified these addresses as orphans from previous WAN connections (before IP change).

The cause are stale entries in the NAPT table after the WAN IP has changed. Outdated but still existing entries translate the private source IP of packets to be sent with an outdated public source IP address. These packets will not be forwarded by the ISP due to invalid source IP.

So it seems to be a bug in Opnsense. Manually flushing the state table after changing the public IP solves the issue and lets the Fritzbox successfully re-register its SIP acounts. I will open a new entry in the issue tracker on github.

[marjohn56]

Have you tried enabling the KIll States in the gateway monitoring in Firewall->Settings->Advanced.

[schnipp]

Have you tried enabling the KIll States in the gateway monitoring in Firewall->Settings->Advanced.

Thanks for the hint, I have tested it, but without success.

In my eyes killing the NAPT table states by monitoring the Gateway would not make any sense due to possible race condictions when cleaning the NAPT table.

The gateway monitoring and renewal of the clients IP address do not have a causal dependancy. In detail, the process of renewing a client's IP address could be fast enough that the parallel acting monitoring process does not recocnize any interruption (because the gateway address does not necessarily change). Furthermore, after performing state killing due to a non responding gateway, new entries with the outdated IP address could introduce into the NAPT state table if the WAN interface still has the old IP address (which is not valid anymore). 

So, it is important to do NAPT state killing after the WAN interface is cleaned up (old IP address removed).

[marjohn56]

OK, well it was worth a try. So what you really need is that when dhclient ( I'm assuming that this is IPv4 ) gets a new IP you want the states cleared at that point?

[franco]

You mean like someone requested 10 days ago and already finished for 18.1.9 this week?

https://github.com/opnsense/core/issues/2414

:D

[marjohn56]

Yes, exactly that. 8)

[franco]

What are the odds, huh...


Cheers,
Franco

[schnipp]

The github post looks like the same issue, so I do not need to open a new item on the issue tracker.
And a patch is already available 8). I will test it the next weekend.

I had a short look at the code snippet and asked myself if there is a need for a configuration option. In general, if a WAN interface gets a new IP and the old IP gets outdated, related entries in the NAT (and firewall) state table should always be removed.

[franco]

This would pose a huge issue for Multi-WAN, especially when you are load-balancing. ;)

I checked with other solutions code and while they flush the NAT table for said IP the connection tracker is not NAT so that's why this is needed alongside... NAT comes after connection tracking so clearing NAT states does not help...


Cheers,
Franco

[schnipp]

This would pose a huge issue for Multi-WAN, especially when you are load-balancing.

In my eyes it depends.

If a network link goes down and the ISP assigns you a new IP address (as a replacement) when the link comes up again, the old IP address becomes invalid. In case a link of a multilink connection goes down the assigned IP address is in general still valid.

Only the entries related to an invalid IP address have to be removed from the NAPT's and firewall's state tables. All other entries should remain. If you trigger a full cleaning of state tables, connections which are still alive will break (e.g. internally routed connection among network interfaces).

[franco]

Connections are tracked via internal IP / External IP, not via NAT'ed IP. There is no way to easily separate the state table.


Cheers,
Franco

[schnipp]

The following command should work, or?

pfctl -k <old_ip> 

[franco]

Hi schnipp,

Yes and no. What is old_ip? The old WAN IP? The connection is initiated by the client, the firewall tracks (internal IP, external IP) for the state, then hits NAT. The return packet hits NAT and is translated to internal IP where the state is found.

So you can:

Kill the state of the firewall's own connections
Kill the state of the internal IP's connections
Kill the state of the external IP's connections

But you can't:

Kill the state of the NAT IP and at the same time flush the state table for unrelated entries internal IP and external IP.


Cheers,
Franco

[schnipp]

With old_ip I mean the previous WAN IP assigned by my ISP. Thanks for the explanation in which order firewall and NAT work together. In this case there is no need to remove states from the firewall, but related ones from the NAT table.

My first workaround used pfctl -F states which was too much. But I'll try the patch. Maybe, both of us mean the same  :)