PfSense drops fragmented IPv6 frames
-
Hi,
I'm having a really strange phenomenon.
pfSense 2.3.2-RELEASE-p1
2001:ab7:: is the provider's network.PPPoE (static IP) –- pfSense --- VoIP network
There's a Fritzbox in the VoIP Network using IPv6 to connect to sipgate.de (German VoIP provider).
Everything works fine except that one important packet doesn't go through.There's an incoming SIP call with Invite, Trying, Ringing etc.When it comes to the point the call get's accepted the Fritzbox sends the corresponding OK to sipgate. This OK I see at the VoIP interface of the firewall. I do NOT see it on the WAN side of the firewall. I do also not see any dropped packets in filter.log. My firewall is sending me an ICMP unreachable though.
The effect is that the calling party still has a ringing tone while the receiving party already accepted the call and also sending RTP.So what is going on? I don't know what this IPv6 fragment packet is for, too. Is it maybe the frame is too big (MTU)?
If this is the wrong board, please move to the right one.![Screen Shot 2017-02-17 at 11.28.07.png](/public/imported_attachments/1/Screen Shot 2017-02-17 at 11.28.07.png)
![Screen Shot 2017-02-17 at 11.28.07.png_thumb](/public/imported_attachments/1/Screen Shot 2017-02-17 at 11.28.07.png_thumb) -
I attach another screenshot from what tcpdump shows me. Could someone please help. I'm getting really desperate about this.
When I look into the data field of this packet I see that it's actually SIP Data. It looks like pfSense drops these packages maybe because the Fritz!Box sends it out fragmented.![Screen Shot 2017-02-26 at 12.50.57_2.png](/public/imported_attachments/1/Screen Shot 2017-02-26 at 12.50.57_2.png)
![Screen Shot 2017-02-26 at 12.50.57_2.png_thumb](/public/imported_attachments/1/Screen Shot 2017-02-26 at 12.50.57_2.png_thumb) -
Yeah drop your MTU first.
-
Yeah drop your MTU first.
I tried several MTU settings, but all failed.
I suppose you mean the MTU setting of the WAN port of my Fritzbox?Edit:
After some investigation I think pfSense might drop those frames wrongly. This bug report sounds like the problem I'm having.
https://redmine.pfsense.org/issues/2762
They say that this is fixed in 2.3 though but I'm running 2.3. -
Hi,
might have the same. Is there an update on this topic?Regards
-
Why do you think the frames are being fragmented? Routers are not supposed to fragment on IPv6.
-
I don't know almost anything about IPv6 or pfSense/FreeBSD, but doesn't Path MTU discovery use ICMP? If pfSense was configured to block unsolicited WAN connections, then an ICMP response would be out of band and get blocked, not letting the client know their packet(s) were being dropped because of MTU issues.
-
ICMP should never be blocked as it's used for so many things. Path MTU detection is one. I've been running pfSense for over a year and not had any problems with this. But then, I haven't created any rules to block ICMP(6). If path MTU detection is not working, then you run the risk of losing packets and not knowing about it, as an IPv6 router is supposed to drop oversize packets and not fragment. When that happens the source is advised of the problem and reduces the size accordingly. The only way to avoid the loss is to set the MTU to 1280, which is the minimum allowed for IPv6. The better way is to let ICMP do it's job.