IP fragmentation, MTU issues using PPPoE Vodafone sure signal
-
Dear All,
This is not strictly a Pfsesnse issue,…, I will appreciate any input very much.
My question
I want to get a new Vodafone Sure Signal (VSS) device to work on a Fibre to the cabinet service (FTTC) with BT in the UK.A bit more detail.
-> Hard to find Vodafone to say what is exactly required for the VSS to work. Some users report it does work, others confirm it not to work. No one as yet know why the VSS does work when it works. Vague comments exist for why it does not.
-> FTTC service requires PPPoE to connect.
-> VSS allow mobiles to work in areas with bad reception.What I did
Seems VSS fail to create secure channel to vodafone due to IP fragmentation.
It seems the packet captures fit exactly what Cisco describe here under "Why the MTU Size Must Be Changed".I have both WAN and LAN MTU settings set to MTU 1464 and MSS set to 1436.
I lowered the MTU to 1300, still no joy.
An extract of one of the tests is here. (The x.x.x.212 device is VSS)My Setup:
pfsense 2 daily updated to latest build.
www
|
BT Fibre to Cabinet
|
BT Modem (I must use this)
|
pfsense 2 in bridge mode (PPPoE) // Also tried with Draytek 2820 doing the PPPoE in bridge mode.
NON NAT
-> option 1: Vodafone Sure Signal with (Public IP) -> does not work – ip fragmentation seem to be at play
|
a. pfSense (Public IPs) -> nat -> private LAN
-> option 2: Vodafone Sure Signal with (private IP) -> does not work -- ip fragmentation seem to be at play
b. DD-WRT router (Public IP) -> nat -> for wifi clientsAny help will be much appreciated.
best regards,
-
No help, I'm afraid, but I'm seeing the same thing.
Having researched this, we are not the only ones. From what I can tell, there is some kind of problem associated with using the Suresignal with PPPoE connections.
Obviously the problem is related to MTU and fragmentation. From what I can gather the Suresignal IPSEC VPN setup expects an MTU of 1500 and, thus, fails with the smaller MTU you get with PPPoE. This ties in with my own wireshark dumps which show the response from Vodafone being corrupted with the first 1480 bytes of the response completely lost, followed by a fragment with offset=1480.
What I am not clear on is where and why this is happening, although I believe the MSS clamping to be irrelevant as I believe that only applies for TCP connections and this is UDP traffic. It's noteworthy that other UDP traffic is likely to be impacted by this bug (wherever it is located), and I have heard reports of DNSSEC traffic being impacted.
More interestingly there are reports of some people who use PPPoE who have this working, so it implies something more subtle than a straight incompatibility.
I am also seeing a correlation with using Draytek modems/routers as a PPPoA-PPPoE bridge. I saw one analysis of the Vigor 120 modem (see "Issues") which blames the modem for blocking the required ICMP "fragmentation needed" responses, and this sort of makes sense but I'm not convinced this is the whole story. Certainly the lack of these messages in response would result in the Vodafone VPN servers not knowing that they needed to use a smaller MTU.
The question is: why is this not getting through (at least for some people).
I actually query the conclusions about the Draytek blocking the ICMP responses as, in my own testing, sniffing from pfSense, I saw no ICMP responses generated. I also did not see the first part of any fragmented packets. I wonder if the analysis above was observing the symptom, not the root cause, as if the fragmented packet does not make it through to the end router (in our case pfSense) then no ICMP reply will be generated in the first place.
Given the Draytek acting as a PPPoA-PPPoE bridge shouldn't actually be taking part in the IP protocol exchange which runs within the PPP session that is created between pfSense and the BRAS, it should be transparent to what happens in the PPP session. I find it hard to believe that Draytek would expend the considerable effort to create a filtering PPP proxy on the modem.
The other thing to consider is the ISP. I have seen other reports of people having trouble with certain ISPs, and I wonder if the trouble is related to the ISP configuration at the BRAS. After all, for incoming traffic, this is the point at which the MTU mismatch is going to occur. Surely it's within the ISP's network that the ICMP response should be generated?
I do have another modem, a Netgear DM111P, which I will try in order to eliminate Draytek devices, specifically, as the problem. The trouble I have is that the DM111P is currently very unstable so it's difficult to test with.
There may, of course, be a simple fix and that is to get Vodafone to manually set the MTU on their servers to a smaller value. There's a thread on their forum which I may suggest this in, although I really don't know if they will take any notice.
-
Probably posting a packet trace can help us give you an answer!
-
I didn't post a packet trace because someone had already posted on above, and because I didn't see much point.
If you are interested, this is what I see:
No. Time Source Destination Protocol Info
3 0.632964 <my-wan-ip> 212.183.133.178 ISAKMP IKE_AUTH
4 0.821435 212.183.133.178 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=3562)As you can see, pfsense is not receiving the first fragment. It's possible this is due to some obscure bug in my Draytek Vigor 120 modem, but it's more likely to be that the far end isn't sending it.
Cheers,
Keith</my-wan-ip></my-wan-ip>
-
Well maybe your draytek is reordering packets or the sending side.
Though you can try disabling scrub rules in pfSense and see if that helps.Though without a complete packet capture i cannot give an proper advice.
-
I tried with scrub disable… no change. I simply don't get the other fragment at all, out of order or otherwise. I just get what I posted above repeated lots of times.
Here's a full dump:
No. Time Source Destination Protocol Info 1 0.000000 <my-wan-ip> 212.183.133.178 ISAKMP IKE_SA_INIT Frame 1 (456 bytes on wire, 456 bytes captured) Null/Loopback Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.178 (212.183.133.178) User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500) Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 2 0.088402 212.183.133.178 <my-wan-ip> ISAKMP IKE_SA_INIT Frame 2 (537 bytes on wire, 537 bytes captured) Null/Loopback Internet Protocol, Src: 212.183.133.178 (212.183.133.178), Dst: <my-wan-ip> (<my-wan-ip> ) User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500) Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 3 0.531727 <my-wan-ip> 212.183.133.178 ISAKMP IKE_AUTH Frame 3 (496 bytes on wire, 496 bytes captured) Null/Loopback Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.178 (212.183.133.178) User Datagram Protocol, Src Port: 17698 (17698), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 4 0.709189 212.183.133.178 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=b0c0) Frame 4 (88 bytes on wire, 88 bytes captured) Null/Loopback Internet Protocol, Src: 212.183.133.178 (212.183.133.178), Dst: <my-wan-ip> (<my-wan-ip> ) Data (64 bytes) 0000 5f dd e7 d9 24 bd 04 e3 64 3c 72 4c 29 5c 86 fe _...$...d<rl)\..<br>0010 44 15 4e c4 91 c2 bb f3 29 7d de 36 36 86 47 b4 D.N.....)}.66.G. 0020 db a1 5c 58 96 5f 31 38 d7 b8 aa 7e 92 f8 a0 f4 ..\X._18...~.... 0030 0e 67 2c ad 7e d2 36 d0 ea 63 bd 8d 32 87 ba e0 .g,.~.6..c..2... No. Time Source Destination Protocol Info 5 4.535214 <my-wan-ip> 212.183.133.178 ISAKMP IKE_AUTH Frame 5 (496 bytes on wire, 496 bytes captured) Null/Loopback Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.178 (212.183.133.178) User Datagram Protocol, Src Port: 17698 (17698), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 6 4.733145 212.183.133.178 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=b769) Frame 6 (88 bytes on wire, 88 bytes captured) Null/Loopback Internet Protocol, Src: 212.183.133.178 (212.183.133.178), Dst: <my-wan-ip> (<my-wan-ip> ) Data (64 bytes) 0000 5f dd e7 d9 24 bd 04 e3 64 3c 72 4c 29 5c 86 fe _...$...d<rl)\..<br>0010 44 15 4e c4 91 c2 bb f3 29 7d de 36 36 86 47 b4 D.N.....)}.66.G. 0020 db a1 5c 58 96 5f 31 38 d7 b8 aa 7e 92 f8 a0 f4 ..\X._18...~.... 0030 0e 67 2c ad 7e d2 36 d0 ea 63 bd 8d 32 87 ba e0 .g,.~.6..c..2... No. Time Source Destination Protocol Info 7 11.740081 <my-wan-ip> 212.183.133.178 ISAKMP IKE_AUTH Frame 7 (496 bytes on wire, 496 bytes captured) Null/Loopback Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.178 (212.183.133.178) User Datagram Protocol, Src Port: 17698 (17698), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 8 11.819566 212.183.133.178 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=c2b8) Frame 8 (88 bytes on wire, 88 bytes captured) Null/Loopback Internet Protocol, Src: 212.183.133.178 (212.183.133.178), Dst: <my-wan-ip> (<my-wan-ip> ) Data (64 bytes) 0000 5f dd e7 d9 24 bd 04 e3 64 3c 72 4c 29 5c 86 fe _...$...d<rl)\..<br>0010 44 15 4e c4 91 c2 bb f3 29 7d de 36 36 86 47 b4 D.N.....)}.66.G. 0020 db a1 5c 58 96 5f 31 38 d7 b8 aa 7e 92 f8 a0 f4 ..\X._18...~.... 0030 0e 67 2c ad 7e d2 36 d0 ea 63 bd 8d 32 87 ba e0 .g,.~.6..c..2... No. Time Source Destination Protocol Info 9 24.707153 <my-wan-ip> 212.183.133.178 ISAKMP IKE_AUTH Frame 9 (496 bytes on wire, 496 bytes captured) Null/Loopback Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.178 (212.183.133.178) User Datagram Protocol, Src Port: 17698 (17698), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 10 24.780409 212.183.133.178 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=d8a7) Frame 10 (88 bytes on wire, 88 bytes captured) Null/Loopback Internet Protocol, Src: 212.183.133.178 (212.183.133.178), Dst: <my-wan-ip> (<my-wan-ip> ) Data (64 bytes) 0000 5f dd e7 d9 24 bd 04 e3 64 3c 72 4c 29 5c 86 fe _...$...d<rl)\..<br>0010 44 15 4e c4 91 c2 bb f3 29 7d de 36 36 86 47 b4 D.N.....)}.66.G. 0020 db a1 5c 58 96 5f 31 38 d7 b8 aa 7e 92 f8 a0 f4 ..\X._18...~.... 0030 0e 67 2c ad 7e d2 36 d0 ea 63 bd 8d 32 87 ba e0 .g,.~.6..c..2...</rl)\..<br></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></rl)\..<br></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></rl)\..<br></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></rl)\..<br></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip> -
I was searching for a slightly different issue and came across this page so thought i'd register and give some hopefully useful input.
I have a VF Sure Signal sitting behind a BT Homehub 2.0 router which connects to a separate BT Infinity VDSL modem. This is a VDSL (FTTC) service from BT - I get about 40Mbps downlink and 8Mbps uplink, using PPPoE. The MTU in the Home Hub 2.0 is fixed at 1500 octets, you cannot change it to my knowledge.
The Sure Signal (SS) works fine (when it is working - it has its moments but generally is okay).
I did a trace on what happens during establishment of the IPsec Security Association between the SS and the Security Gateway (SeGW) in the Vodafone network. I have a PC running Wireshark attached to an Ethernet hub capturing all packets between the SS and the Homehub.
The first IKE_SA_INIT packet exchange (the Initial IKEv2 exchange) goes through fine - you can see the options being negotiated for DH key exchange, hash and encryption algorithms as well as the NAT-Traversal detection hash. Both these packets are in the order of 500 octets or so on the wire.
The next packet from the SS to the SeGW switches UDP port from 500 to 4500 - so the system has correctly detected there is a NAT in the path and switched to UDP port 4500 as per RFC 3947 (NAT-T). This is the 1st IKE_AUTH packet in the IKEv2 phase 1 sequence and therefore most of the payload is encrypted using the keys exchanged in the initial negotiation so you cannot see what is inside it. This is around 360 octets in size.
There is then an IKE_AUTH response from the SeGW to the SS. This packet is fragmented. Wireshark reports that one fragment is 1506 octets and the other is 60 octets as captured - although strangely it seems to get the final reassembled packet size wrong. Probably a bug in WS.
1506 octets as captured on the LAN side of the router means the frame is going to be 1506 + 6 (PPPoE header) + 2 (PPP header) + 4 (Ethernet CRC) = 1518 octets on the PPPoE interface on the WAN side of the router (no surprises there). So an MTU of 1500 is going to be required for this packet in the network (assuming that the sender cannot or will not alter its MTU if notified)
Anyway - there are two points to make here.
1. The SS works fine for me over the BT VDSL/PPPoE service with a default MTU in the homehub of 1500 octets.
2. The one reason I can think of off-hand for why the IKE_AUTH response packet from the SeGW is so large and is being fragmented in the 1st place is that it may contain a full copy of the X.509 certificate for the SeGW. RFC 4306 Section 1.2 states that it is optional for both the initiator or responder to send a copy of its relevant certificates in the IKE_AUTH message - it looks like this is what the SeGW is doing in its response (a cert is often about a 1KB binary or text file). I have seen similar issues in other implementations of the IKEv2 exchange where a client implementation is not able to properly re-assemble a packet that is fragmented due to this inclusion of the certificate in the response.
Obviously the SS is designed to do a proper reassembly… but if you don't actually receive all the fragments (and from the trace you can see the offset for the second fragment is at 1480 octets, so you know the piece you are missing is larger than the MTU you have set) then the SS can't re-assemble it. I strongly suspect that even if the VF SeGW receives an ICMP message to set a lower MTU then it ignores it anyway and carries on using its default MTU for transmission. Hence your router (assuming it receives the large fragment) will keep on throwing it away and the process will repeat until the SS gets fed up and stops.
I haven't tried it but it should be possible to trace the Ethernet between the router and the separate VDSL modem for Infinity (it is just an Ethernet connection after all) so you might be able to capture the PPPoE packets there to see if you are at least receiving the first, larger fragment there. This would help narrow down where the problem is occurring.
-
I was searching for a slightly different issue and came across this page so thought i'd register and give some hopefully useful input.
Hi Freddy,
Thanks for this. This is interesting information, partly because FTTC is coming to my area in a few months, and it tells me that upgrading to it should cure this issue! ;)I haven't tried it but it should be possible to trace the Ethernet between the router and the separate VDSL modem for Infinity (it is just an Ethernet connection after all) so you might be able to capture the PPPoE packets there to see if you are at least receiving the first, larger fragment there. This would help narrow down where the problem is occurring.
I was considering doing this between my pfSense and Vigor modem. The problem is I don't have a hub any more (my test hub died) and I haven't had time to mess around setting up a switch with mirror ports as it involves making quite a few changes to my network. If I get a chance to do it I will post results.
Cheers,
Keith
-
You can capture from pfSense itself!?
-
@ermal:
You can capture from pfSense itself!?
That's what I did above for the PPP connection. What I hadn't tried (because it hadn't occurred to me to try) was capturing directly from the OPT interface that the modem is connected to. I've tried this now and it seems to work.
However, there's no easy way to filter just the suresignal stuff at capture time as all of the packets are (of course) PPPoE between my IP and the ISPs gateway IP, so I need to do a bit of messing around with wireshark.
Will report back…
Cheers,
Keith
-
I was considering doing this between my pfSense and Vigor modem. The problem is I don't have a hub any more (my test hub died) and I haven't had time to mess around setting up a switch with mirror ports as it involves making quite a few changes to my network. If I get a chance to do it I will post results.
I know what you mean. I had to go to eBay to pick up an Ethernet hub for testing - 25 quid later for a really old Nortel 8 port business hub … but it does the job!
I find there is confusion about PPPoE MTU settings out there. The actual RFC 2516 states the PPP payload MTU should be no more than 1492 octets, so when you add the PPPoE/PPP headers (6 + 2) and Ethernet MAC (18) you end up with a 1518 octet Ethernet packet, which makes sense. In this case, the MTU for a router that is forwarding the IP/PPPoE/PPP PDU between two interfaces would require a minimum MTU of 1500 octets to avoid fragmentation.
Some people seem to treat 1492 as the maximum overall MTU value for the entire Ethernet frame and then deduct the Ethernet MAC and PPP/PPPoE headers from that. So you end up with 1492 - 6 - 2 - 18 = 1466 octets or so as the 'recommended' MTU value to use for the payload. This shouldn't really cause any problems if you were to set it, until you come up against a sender that doesn't want to play ball with changing its MTU.
The SeGW's that are used for a system like the VF SS service are pretty hefty pieces of hardware designed to simultaneously support hundreds of thousands of high speed IPsec tunnels … to be able to do this highly computational stuff efficiently a lot of processing is done in canned hardware implementations (or NPs) so it's maybe not in their interest to have to worry about fragmenting packets as well for the occasional customer that has a lower MTU set as this would mean having to further increase complexity.
Interestingly, I see that the Don't Fragment bit on packets received from the SeGW is not set so ICMP messages for "destination unreachable, datagram too big but DF bit set" may not be generated back to the SeGW anyway.
-
I was considering doing this between my pfSense and Vigor modem. The problem is I don't have a hub any more (my test hub died) and I haven't had time to mess around setting up a switch with mirror ports as it involves making quite a few changes to my network. If I get a chance to do it I will post results.
I know what you mean. I had to go to eBay to pick up an Ethernet hub for testing - 25 quid later for a really old Nortel 8 port business hub … but it does the job!
Actually I found I could do it direct from pfSense as suggested by ermal above. This may not apply to you (Freddy) as you haven't said that you are using pfSense. But for those that are:
To do this you need to create a new OPT interface using the physical interface that your modem is connected to. You should already have a "WAN" interface set up for PPPoE. Fo instance, my modem is connected to rl0 so this appears as using Network port PPPOE0(rl0). You can then set another interface up using just rl0. In my case I had already done that to get tot the modem web/telnet interface.
You can then put packet capture on this interface.
I find there is confusion about PPPoE MTU settings out there. The actual RFC 2516 states the PPP payload MTU should be no more than 1492 octets, so when you add the PPPoE/PPP headers (6 + 2) and Ethernet MAC (18) you end up with a 1518 octet Ethernet packet, which makes sense. In this case, the MTU for a router that is forwarding the IP/PPPoE/PPP PDU between two interfaces would require a minimum MTU of 1500 octets to avoid fragmentation.
In normal circumstances, 1492 is the largest MTU supported by PPPoE, as you suggest and RFC 2516 state. However, it is possible to break past the normal Ethernet frame limitation in order to accommodate the extra 8 octets. This breaks traditional Ethernet rules, but there is a precedent for this in Jumbo frames. I have seen this referred to as "baby jumbo frames" as the frames are only slightly bigger. This is covered by RFC 4638. Apparently the BT VDSL service will support this as long as your equipment will support it. Some devices, like the Firebrick, do support this.
I'm not sure what the situation with pfSense would be here. I'm guessing pfSense doesn't currently support RFC 4638, but I'm also guessing that the dependency is largely on the actual hardware it is deployed on and the drivers for the Ethernet ports, but it seems like it would be a desirable capability to have on pfSense.
In my case I would also need my modem to support it.
Some people seem to treat 1492 as the maximum overall MTU value for the entire Ethernet frame and then deduct the Ethernet MAC and PPP/PPPoE headers from that. So you end up with 1492 - 6 - 2 - 18 = 1466 octets or so as the 'recommended' MTU value to use for the payload. This shouldn't really cause any problems if you were to set it, until you come up against a sender that doesn't want to play ball with changing its MTU.
Yes I have seen many variations of this. In theory PPP should do the right thing and negotiate the best MTU that both ends support. I have no feelings on whether this is the case in practice or not.
Note that some ISPs (especially, I think, in the US) offer a service which is PPPoEoA, in contrast to what we are talking about here which is a PPPoA service bridged to PPPoE. With PPPoEoA you have an extra layer in which uses an additional 24 octets. in this case you end up with an MTU of 1468.
FYI, the reason I went with 1456 is that it's supposed to be a more efficient frame size for ATM based networks (as ADSL typically is). The reason is ATM has fixed sized cells which the IP packet is encapsulated into. If the packet is bigger than one cell, it uses multiple cells. If the packet doesn't exactly fill the cells, you end up with cells containing empty padding. 1456 is supposed to be the magic number which completely fills the ATM cells with no padding. Packets above this will result in a cell per packet which is mostly empty. However, I have seen other descriptions which suggest that 1478 is the optimum if your service uses VC based multiplexing (which I believe mine does).
The SeGW's that are used for a system like the VF SS service are pretty hefty pieces of hardware designed to simultaneously support hundreds of thousands of high speed IPsec tunnels … to be able to do this highly computational stuff efficiently a lot of processing is done in canned hardware implementations (or NPs) so it's maybe not in their interest to have to worry about fragmenting packets as well for the occasional customer that has a lower MTU set as this would mean having to further increase complexity.
This might be the case, but there seems to be a significant number of customers impacted by this issue. It may well be worth their while tweaking the MTU on the SeGW's to 1492 to cure the issue. It seems their devices are having to fragment these packets into two fragments already anyway. I don't see that fragmenting into two packets with different sizes will make any real difference to anything. Of course there is the possibility that other packets which would have fit into the 1500 octet MTU would now get fragmented, but this is statistically fairly unlikely. And the savings on handling the support calls alone might make this worthwhile.
Interestingly, I see that the Don't Fragment bit on packets received from the SeGW is not set so ICMP messages for "destination unreachable, datagram too big but DF bit set" may not be generated back to the SeGW anyway.
OK, this is VERY useful information. I was unable to determine if this was the case or not as I wasn't seeing these packets. In this case the fragmentation should be done within the ISPs network, and it suggests this isn't being done properly.
Cheers,
Keith
-
OK, results of PPPoE sniffing. Full packet dump below but, basically, these packets aren't appearing on the PPP layer either (unless the modem is filtering them out during bridging, which I find pretty unlikely).
No. Time Source Destination Protocol Info 1317 17.077093 <my-wan-ip> 212.183.133.179 ISAKMP IKE_SA_INIT Frame 1317 (474 bytes on wire, 474 bytes captured) Ethernet II, Src: Fabiatec_08:99:2e (00:04:a7:08:99:2e), Dst: Draytek_38:b5:c2 (00:50:7f:38:b5:c2) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.179 (212.183.133.179) User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500) Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 1319 17.431679 212.183.133.179 <my-wan-ip> ISAKMP IKE_SA_INIT Frame 1319 (555 bytes on wire, 555 bytes captured) Ethernet II, Src: Draytek_38:b5:c2 (00:50:7f:38:b5:c2), Dst: Fabiatec_08:99:2e (00:04:a7:08:99:2e) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: 212.183.133.179 (212.183.133.179), Dst: <my-wan-ip> (<my-wan-ip> ) User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500) Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 1320 17.875322 <my-wan-ip> 212.183.133.179 ISAKMP IKE_AUTH Frame 1320 (514 bytes on wire, 514 bytes captured) Ethernet II, Src: Fabiatec_08:99:2e (00:04:a7:08:99:2e), Dst: Draytek_38:b5:c2 (00:50:7f:38:b5:c2) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.179 (212.183.133.179) User Datagram Protocol, Src Port: 5646 (5646), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 1323 17.962236 212.183.133.179 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=d5cf) Frame 1323 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: Draytek_38:b5:c2 (00:50:7f:38:b5:c2), Dst: Fabiatec_08:99:2e (00:04:a7:08:99:2e) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: 212.183.133.179 (212.183.133.179), Dst: <my-wan-ip> (<my-wan-ip> ) Data (16 bytes) 0000 95 f4 16 30 bf 05 82 6e 7e 9f 8b 46 6f 8c a9 20 ...0...n~..Fo.. No. Time Source Destination Protocol Info 1342 21.878812 <my-wan-ip> 212.183.133.179 ISAKMP IKE_AUTH Frame 1342 (514 bytes on wire, 514 bytes captured) Ethernet II, Src: Fabiatec_08:99:2e (00:04:a7:08:99:2e), Dst: Draytek_38:b5:c2 (00:50:7f:38:b5:c2) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.179 (212.183.133.179) User Datagram Protocol, Src Port: 5646 (5646), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 1345 21.970402 212.183.133.179 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=dca9) Frame 1345 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: Draytek_38:b5:c2 (00:50:7f:38:b5:c2), Dst: Fabiatec_08:99:2e (00:04:a7:08:99:2e) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: 212.183.133.179 (212.183.133.179), Dst: <my-wan-ip> (<my-wan-ip> ) Data (16 bytes) 0000 95 f4 16 30 bf 05 82 6e 7e 9f 8b 46 6f 8c a9 20 ...0...n~..Fo.. No. Time Source Destination Protocol Info 1391 29.083752 <my-wan-ip> 212.183.133.179 ISAKMP IKE_AUTH Frame 1391 (514 bytes on wire, 514 bytes captured) Ethernet II, Src: Fabiatec_08:99:2e (00:04:a7:08:99:2e), Dst: Draytek_38:b5:c2 (00:50:7f:38:b5:c2) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.179 (212.183.133.179) User Datagram Protocol, Src Port: 5646 (5646), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 1394 29.162119 212.183.133.179 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=e936) Frame 1394 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: Draytek_38:b5:c2 (00:50:7f:38:b5:c2), Dst: Fabiatec_08:99:2e (00:04:a7:08:99:2e) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: 212.183.133.179 (212.183.133.179), Dst: <my-wan-ip> (<my-wan-ip> ) Data (16 bytes) 0000 95 f4 16 30 bf 05 82 6e 7e 9f 8b 46 6f 8c a9 20 ...0...n~..Fo.. No. Time Source Destination Protocol Info 1482 42.050727 <my-wan-ip> 212.183.133.179 ISAKMP IKE_AUTH Frame 1482 (514 bytes on wire, 514 bytes captured) Ethernet II, Src: Fabiatec_08:99:2e (00:04:a7:08:99:2e), Dst: Draytek_38:b5:c2 (00:50:7f:38:b5:c2) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: <my-wan-ip> (<my-wan-ip> ), Dst: 212.183.133.179 (212.183.133.179) User Datagram Protocol, Src Port: 5646 (5646), Dst Port: ipsec-nat-t (4500) UDP Encapsulation of IPsec Packets Internet Security Association and Key Management Protocol No. Time Source Destination Protocol Info 1485 42.152763 212.183.133.179 <my-wan-ip> IP Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=000d) Frame 1485 (68 bytes on wire, 68 bytes captured) Ethernet II, Src: Draytek_38:b5:c2 (00:50:7f:38:b5:c2), Dst: Fabiatec_08:99:2e (00:04:a7:08:99:2e) PPP-over-Ethernet Session Point-to-Point Protocol Internet Protocol, Src: 212.183.133.179 (212.183.133.179), Dst: <my-wan-ip> (<my-wan-ip> ) Data (16 bytes) 0000 95 f4 16 30 bf 05 82 6e 7e 9f 8b 46 6f 8c a9 20 ...0...n~..Fo..</my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip></my-wan-ip>Cheers,
Keith
-
As an aside, I raised a support ticket with my ISP on this.
They are suggesting that my network is "too complex" which is a ridiculous statement.
I'm using a standard off-the-shelf DSL modem and PPPoE. They do not provide any router or modem themselves, and they advertise it as a "business" service (and charge accordingly), and business customers are far more likely to be using a PPPoE device instead of a 40 quid consumer-grade router.
I'm going to make my feelings known, but I suspect I will be changing ISP in the near future.
Cheers,
Keith
-
In normal circumstances, 1492 is the largest MTU supported by PPPoE, as you suggest and RFC 2516 state. However, it is possible to break past the normal Ethernet frame limitation in order to accommodate the extra 8 octets. This breaks traditional Ethernet rules, but there is a precedent for this in Jumbo frames. I have seen this referred to as "baby jumbo frames" as the frames are only slightly bigger. This is covered by RFC 4638. Apparently the BT VDSL service will support this as long as your equipment will support it. Some devices, like the Firebrick, do support this.
I'm not sure what the situation with pfSense would be here. I'm guessing pfSense doesn't currently support RFC 4638, but I'm also guessing that the dependency is largely on the actual hardware it is deployed on and the drivers for the Ethernet ports, but it seems like it would be a desirable capability to have on pfSense.
Having checked into this, neither the Realtek (rt) or Agere (et) drivers/hardware for BSD do not seem to support MTUs larger than 1500, so it's probably not supported on my hardware.
Cheers,
Keith
-
Fascinating stuff!
Do you mind if I ask who your ISP is?
Steve
-
I would rather not say at the moment, as I still have a ticket open, and I would rather give them the chance to redeem themselves before posting negative publicity which can be directly attributed to them.
The thing that bothers me is I'm pointing out a flaw in their network, and they don't seem to understand that I'm trying to help them. Quite frankly I'm not that bothered about getting the SureSignal device working (I got it sent to me for free by my Vodafone Business Account Manager). What I do care about is having a professional, competent, and clueful ISP, especially when I have been paying a considerably premium to get a "business grade" service.
They keep saying things like "We don't support PPPoE Authentication" but then promote and sell a premium version of their service "for business use", as far as I'm concerned these two statements are mutually incompatible.
It's not really impacting me in any practical way at the moment, but if they've still not sorted or at least acknowledged it in a few months time when FTTC is supposed to be in my area, I'll be using switching to a new provider. At that point I will be only too happy to share who they are.
Cheers,
Keith
-
That seems fair.
If your ISP is llu type then I think you have a chance. If you are reliant on btw then good luck!
I haven't experinced any problems here with either the vigor 120 or the fttc modem but I don't have a vss. It would be interesting to run a test but I'm not sure what might show up the problem.Steve
-
That seems fair.
If your ISP is llu type then I think you have a chance. If you are reliant on btw then good luck!It is (apparently) LLU, which is why it is so annoying to me that they don't seem willing to entertain checking this or at least passing it along to someone in their team who is more clueful.
Ultimately, the answer might come back as "yes we know this is an issue but we are unable/unwilling to support this because of xxxx", and that's an answer I would accept. There may be good technical/operation reasons.
Incidentally, I have heard that people who use a Be line have had more success. I believe this is down to their use of PPPoE on their backhaul circuits which means they have an MTU of 1492 across most of their access network anyway and, therefore, know how to configure their kit to support this properly.
Cheers,
Keith
