Telecom Ultra Fibre with Fortigate

Forums › Spark New Zealand (including Skinny and BigPipe) › Telecom Ultra Fibre with Fortigate

Paul1977

4785 posts

Uber Geek

#142808 25-Mar-2014 12:33

Hi

I have just had ultra fibre installed through Telecom. I am in Christchurch so it is Enable fibre.

Has anyone had success in connecting a Fortigate router connected directly to the ONT to handle the PPPoE?

The Telecom supplied modem works fine, but the Fortigate fails to connect.

Even if you don't have a Fortigate, any tricks learned from using other non ISP supplied routers would be helpful.

Thanks in advance.

networkn

Networkn
30223 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#1012386 25-Mar-2014 12:38

What model and OS Version?

NordVPN

Protect your online activity with NordVPN (affiliate link).

Zeon

3876 posts

Uber Geek

Trusted

#1012394 25-Mar-2014 12:53

Does enable need vlan10?

Speedtest 2019-10-14

networkn

Networkn
30223 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#1012395 25-Mar-2014 12:56

Zeon: Does enable need vlan10?

Depends if tagging is enabled, it can be or not, it's at the RSP(or end user) request.

cbrpilot

890 posts

Ultimate Geek

Trusted

Spark NZ

#1012406 25-Mar-2014 13:02

Yes, you'll need to set the WAN frames to VLAN 10.

My views are my own, and may not necessarily represent those of my employer.

Paul1977

4785 posts

Uber Geek

#1012560 25-Mar-2014 16:41

Thanks for the replies.

It's a FortiWiFi 60C running 5.0 patch 5

My reply is a bit late because Gen-i decided to cut off our ADSL before I had even got the Fibre on the Fortigate up or done any testing.

VLAN with ID 10 worked, so thanks for that.

I've been frantically reconfiguring the firewall to get us up and all our rules back in place on the newly configured interface. Not how I planned to spend the afternoon, the plan had been to leisurely test the fibre and cut over once everything was happy and preconfigured (but a mistake at Gen-i put an end to that idea).

Another question that someone here smarter than me can probably answer (and the main reason I wanted to thoroughly test the Fortigate before cutting over). It's a little long so I hope it makes sense:

Config settings from Gen-i say that any third party router "Must support MTU of 1500 bytes as per RFC4638. If RFC4638 is not supported then the modem must support MSS clamping to avoid any path mtu issues".

Fortinet's list of supported RFCs does not list 4638.

The response I got from Fortinet was "MTU size of all interfaces is 1500 by default. If the ISP device is set to allow 1500B frames or 1492 as in most PPPoE connections, it should be fine. If they have the MTU bigger that 1500, then you need to override and set the larger value."

I'm not 100% confident in the response as it seems to contradict some of their own documentation, and I have had some incorrect info from them before.

As it now stands it is up and appears to be running fine, is their a way I can test for MTU problems? Or does anyone know if I should be manually setting MTU to 1500?

Thanks

cbrpilot

890 posts

Ultimate Geek

Trusted

Spark NZ

#1012633 25-Mar-2014 18:46

MTU is a tricky topic. I have no idea how familiar you are with MTU (layer 2 payload size) and it's relation to MSS (layer 4 (TCP) payload size).

Telecom will support either the 1492 or the 1500 byte PPP MTU.
If your device is negotiating a 1500 byte PPP MTU, then it need not support MSS clamping as it will support a full 1500 byte IP packet - which is what Ethernet will support by default.
It's only if your device wanted 1492 wherein it must support MSS clamping. What MSS clamping does is to artifically force the negotiated Maximum (TCP) Segement Size (MSS) down to 1452 in order to fit within the 1492 PPP payload size (1452 + 20 byte TCP header + 20 byte IP header = 1492). 1492 + 8 byte PPP header = 1500 byte MTU, which Ethernet will support by default.
I would say it'd be very rare for a PPPoE device not to be able to support MSS clamping.

RFC4638 is a method for both ends of a PPPoE link to advise each other that they can support a full 1500 byte (in this case) PPP payload, which means a 1508 Ethernet MTU.
From what you're saying, your device may not support this.
That is ok, but it will need to support MSS clamping, which it's almost unheard of for a device not to.

So to answer your question, if it's set to 1492 and there are some websites you cannot access, then more than likely your modem doesn't support MSS clamping.
I'm not familiar off the top of my head which sites require a full 1500 byte MTU and which do not. I know that about 5 years ago www.download.com would try and negotiate a 1500 byte MTU, but can't guarantee that is still the case.

There are a number of ways to be sure that your device supports MSS-camping, but none of them too straight forward. E.g. mirror the WAN port to one of the Eth ports on the LAN interface, and compare traces (using wireshark) off your pc and the mirror port to see if the device is lowering the requested MSS values within the TCP headers. No idea how technical you are though, so that may all be greek to you...

My views are my own, and may not necessarily represent those of my employer.

plambrechtsen

1948 posts

Uber Geek
Inactive user

#1012701 25-Mar-2014 20:20

networkn:
Zeon: Does enable need vlan10?

Depends if tagging is enabled, it can be or not, it's at the RSP(or end user) request.

Just a heads up on that.. all devices connected to Telecom Retail UFB you need PPPoE over vlan 10 tagging for it to work. This isn't optional or something that can changed on a per subscriber basis for any CPE that doesn't support vlan10 tagging over PPPoE.

I'm also 99.9% sure that also applies to Gen-I too..

Paul1977

4785 posts

Uber Geek

#1012916 26-Mar-2014 09:31

cbrpilot: MTU is a tricky topic. I have no idea how familiar you are with MTU (layer 2 payload size) and it's relation to MSS (layer 4 (TCP) payload size).

Telecom will support either the 1492 or the 1500 byte PPP MTU.
If your device is negotiating a 1500 byte PPP MTU, then it need not support MSS clamping as it will support a full 1500 byte IP packet - which is what Ethernet will support by default.
It's only if your device wanted 1492 wherein it must support MSS clamping. What MSS clamping does is to artifically force the negotiated Maximum (TCP) Segement Size (MSS) down to 1452 in order to fit within the 1492 PPP payload size (1452 + 20 byte TCP header + 20 byte IP header = 1492). 1492 + 8 byte PPP header = 1500 byte MTU, which Ethernet will support by default.
I would say it'd be very rare for a PPPoE device not to be able to support MSS clamping.

RFC4638 is a method for both ends of a PPPoE link to advise each other that they can support a full 1500 byte (in this case) PPP payload, which means a 1508 Ethernet MTU.
From what you're saying, your device may not support this.
That is ok, but it will need to support MSS clamping, which it's almost unheard of for a device not to.

So to answer your question, if it's set to 1492 and there are some websites you cannot access, then more than likely your modem doesn't support MSS clamping.
I'm not familiar off the top of my head which sites require a full 1500 byte MTU and which do not. I know that about 5 years ago www.download.com would try and negotiate a 1500 byte MTU, but can't guarantee that is still the case.

There are a number of ways to be sure that your device supports MSS-camping, but none of them too straight forward. E.g. mirror the WAN port to one of the Eth ports on the LAN interface, and compare traces (using wireshark) off your pc and the mirror port to see if the device is lowering the requested MSS values within the TCP headers. No idea how technical you are though, so that may all be greek to you...

I can follow a good portion of that.

You say "Telecom will support either the 1492 or the 1500 byte PPP MTU", wouldn't that mean the router doesn't need to support RFC4638?

My concern was the Fortinet guy might be talking about the Ethernet frame size being 1500 and not realizing about the 8 byte PPPoE overhead (which as you said makes 1508).

I tried download.com and it only half loaded the first time, but worked fine second try - so not sure if that means anything or not.

MSS clamping I admit I am not familiar with, is this generally something that happens automatically on the router or has to be configured?

We host an Exchange server, so my main concern right now is mail flow. This may be a dumb question, but could MTU problems cause mail loss (either incoming or outgoing) without an NDR?

cbrpilot

890 posts

Ultimate Geek

Trusted

Spark NZ

#1012960 26-Mar-2014 10:03

The modem only needs to support RFC4638 in order to be able to run 1500 byte PPP MTU. What that does is to include an extra tag into the PPPoE Discovery packets called PPP-Max-Payload (off the top of my head) which tells the far end that it's ok to negotiate a 1500 byte PPP MTU, with the full knowledge that it will mean jumbo ethernet frames (i.e. >1500 bytes of payload).

I have no idea about download.com anymore, and don't currently have the tools to look into it. If it loaded fully, then it's probably fine.

MSS clamping should be automatic.

Personally I'm not a mail expert, so I'm not sure I can accurately answer your question. I.e. please take what I say in regards to mail with a grain of salt. What will generally happen if you're having an MTU issue will be that either the frames that are too big will arrive at the Broadband Network Gateway (BNG) (which is the router at the other end of the PPP link) and get fragmented there, and sent for delivery to your modem (and reassembled there). No problems here. The problems will occur if one or both ends set the "Do Not Fragment" bit in the IP header - which will cause oversize frames to be dropped instead of fragmented. I think that's dependant on the OS and software at the far end.

Given the packet loss and the fact that mail protocols use TCP, I can't imagine a world where you'd get a silent failure here. I.e. you'll be getting error messages saying things like it lost communication with the mail server or similar.

Hope that helps.

My views are my own, and may not necessarily represent those of my employer.

Paul1977

4785 posts

Uber Geek

#1012991 26-Mar-2014 10:29

cbrpilot: The modem only needs to support RFC4638 in order to be able to run 1500 byte PPP MTU. What that does is to include an extra tag into the PPPoE Discovery packets called PPP-Max-Payload (off the top of my head) which tells the far end that it's ok to negotiate a 1500 byte PPP MTU, with the full knowledge that it will mean jumbo ethernet frames (i.e. >1500 bytes of payload).

I have no idea about download.com anymore, and don't currently have the tools to look into it. If it loaded fully, then it's probably fine.

MSS clamping should be automatic.

Personally I'm not a mail expert, so I'm not sure I can accurately answer your question. I.e. please take what I say in regards to mail with a grain of salt. What will generally happen if you're having an MTU issue will be that either the frames that are too big will arrive at the Broadband Network Gateway (BNG) (which is the router at the other end of the PPP link) and get fragmented there, and sent for delivery to your modem (and reassembled there). No problems here. The problems will occur if one or both ends set the "Do Not Fragment" bit in the IP header - which will cause oversize frames to be dropped instead of fragmented. I think that's dependant on the OS and software at the far end.

Given the packet loss and the fact that mail protocols use TCP, I can't imagine a world where you'd get a silent failure here. I.e. you'll be getting error messages saying things like it lost communication with the mail server or similar.

Hope that helps.

Thanks for all that.

I would have thought the same about the emails that a silent failure would be very unusual. I asked because I sent myself an email after our ADSL had been prematurely disconnected but before the fibre was up and running, and it still hasn't arrived and I haven't received an NDR as yet. And that was a good 18 hours ago.

cbrpilot

890 posts

Ultimate Geek

Trusted

Spark NZ

#1013018 26-Mar-2014 10:59

Little worrying that it hasn't arrived. Have you tried sending a second?

I would be fairly confident that whatever the issue that has caused this, it is not an MTU issue.

As I've said, I'm not a mail expert, so I'm not going to pretend to try and give you advice on how to proceed here! :)

My views are my own, and may not necessarily represent those of my employer.

Paul1977

4785 posts

Uber Geek

#1013065 26-Mar-2014 11:48

cbrpilot: Little worrying that it hasn't arrived. Have you tried sending a second?

I would be fairly confident that whatever the issue that has caused this, it is not an MTU issue.

As I've said, I'm not a mail expert, so I'm not going to pretend to try and give you advice on how to proceed here! :)

When they were unable to reinstate our ADSL in a timely fashion I instead got them to move our old ADSL static IP onto the new Fibre connection and everything has been coming through since then (as far as I am aware).

As far as I'm aware if the listed MX is unavailable then the sending server should periodically retry. But the test was from a Yahoo Xtra account, so I can't see if it is stuck in an outgoing queue there, and that wouldn't help me for any other possible emails sent to us during that time frame anyway.

We shuffled some MX records as well while we were coming up with the best plan to get the mail flow back in the shortest time frame, but I can't see anything that would cause silent failures like this. I'm hopeful that it may still turn up or an NDR bounce back (along with any other emails that may have been affected).

Paul1977

4785 posts

Uber Geek

#1013238 26-Mar-2014 15:35

Well, and NDR turned up exactly 24 hours after sending. It doesn't say why it failed, just "message expired".

Since everything is coming through correctly now I'm not going to worry too much. My concern about silent failures can be laid to rest. the failure is still unexplained, but as long as it was isolated to this short time period and that NDRs went back to senders I'm happy.