ICMPv6 Packet too Big and SIP (sipgate)

[Dark-Sider]

Hi,

I'm running an AVM Fritz!Box router as a LAN client for my VOIP needs. It's a neat all-in-one PBX solution for internal ISDN, DECT and SIP phones. Internet is provided by the German ISP M-Net through FTTH/GPON. OPNsense connects via PPPoE to the Internet (MTU set to 1492 in the pppoe options).

To avoid NAT issues with SIP I configured all SIP-accounts as IPv6 only. Under Firewall settings I have allowed sipagte's servers so they can talk to my AVM Fritz!Box.

I'm using both, sipagte and my ISP's voip service. While my ISP's voip works fine, incoming sipagate calls cannot be answered (caller still hears the phone ringing although the call was picked up).

To troubleshoot the problem I did some packet capturing. As it turns out the SIP/SDP 200 OK packet that is sent  to sipgate is "rejected" by OPNsense with an ICMPv6 "Packet too big" and therefore never reaching my voip provider. The ICMPv6 Packet Too Big contains the correct MTU of 1484 (the value that is displayed und calculated MTU for PPP in the pppoe options), the Packet that is rejected has a packet size of 1494.

What would be the expected behavior there? Is the Fritz!Box expected to rentransmit the packet with a smaller packet size or is OPNsense expected to refragment the packet to fit the MTU? If so, what setting do I miss?

regards,
Fabian

[robgnu]

Hi,
I had the same issue yesterday. A FRITZ!Box behind the firewall. The Box is doing IPv4 VoIP to the Telekom and IPv6 VoIP to Sipgate. For the moment I switched the Sipgate also to IPv4, but this can't be the solution.
I also had this issue on an pfSense installation. So this may be a FreeBSD issue?

Any ideas?

Robert

[Maurice]

Intermediate routers never fragment IPv6 packets. The SIP client must perform path MTU discovery and generate appropriately sized packets.

You could test your Sipgate account with a softphone on a device in the same LAN. If that works, it might be a FritzBox issue.

[Dark-Sider]

Here are some updates on this issue. I have had opened a ticket with AVM the manufacturer of the VOIP-Router. I sent them packet captures and a lot of details. They concluded (and I might have to agree) that issue has to be on the firewall. So I did some more testing tonight and the results are really strange. The MTU for my PPPoE device is set to 1492, the LAN interface MTU is 1500.

The SIP response going out to sipgate is too big fit in one packet, so the Fritz!Box already devides it into 2 packets: 1st packet has a length of 1502 and the 2nd packet a length of 237. Those lengths are the full physical ethernet frames reaching opnsense. So 18 bytes ethernet header and footer are deducted, yeilding a full IPv6 size of 1484 which is way below 1492. But opnsense replies to my Fritz!Box with ICMPv6 Packet Size too big.

I dumped the SIP-Payload of both fragments and recombined them to the total size of 1604 Bytes (just the SIP response), opened and piped it to netcat on a linux box in my LAN. I chose sipgates server as destination and used the 5060 port. The packet was again fragmented by nc/linux to the exact same 2 fragment sizes as the fritzBox did, but it went through (!!!). When I compared the headers I only found that the fritzBox chose a flow label of 0x0 and nc put in some (maybe not so) random hex.

When doing a packet capture on the pfsense (filtering to the packet sending machine), I always get those messages:

Code Select Expand


LAN
vmx2 20:44:11.309778 IP6 2001:a61:xxx > 2001:ab7::4: frag (0|1440) 38065 > 5060: UDP, bad length 1604 > 1432
LAN
vmx2 20:44:11.309787 IP6 2001:a61:xxx > 2001:ab7::4: frag (1440|172)


however when the Fritz!Box sends it, it gets dropped and that ICMPv6 message is returned. - the other numbers (except for the source ip) stay the same...

over at pfsense I found that there apparently existed a FreeBSD bug: https://forum.netgate.com/topic/123169/problems-with-mtu-and-dropped-packets/10 https://redmine.pfsense.org/issues/8165 but as opnsense is already at 12.x I think this should be fixed?!

Edit: The issue persists after upgrading to 21.1.3

Edit2: more testing:
This actually might be related to the bug I linked above. I did the following testing:
pfctl -d      The packets go through
pfctl -e      The packets get blocked again with the "too big" message


regards
Darky