PPPoE WAN MTU and site to stie VPNs
Hello, I've been troubleshooting site to site VPNs at a location provisioned with a PPPoE internet circuit. The below SonicWALL article seems to indicate the best MTU setting on the WAN interface is 1452 when using PPPoE.
I've got a strange problem though. Out of the 8 site to site VPNs I have setup, only two are coming up. When this firewall was first deployed, they all seemed to work. I've experienced this problem before using PPPoE internet circuits. Even with different generation firewalls. This model is a TZ270, but the TZ300 (Gen 6) did the same thing.
If you check the log on the remote firewall for a VPN that is not coming online, you see "remote party timeout" entries. No amount of deleting the VPNs and re-creating seems to help, I think this has something to do with the WAN MTU, but am just guessing. Anyone out there run into this?
Regards,
Adam Tyler
Answers
@AdamTheManTyler
Are you sure the remaining VPN tunnels pre-shared key and configurations are same of the other end units?
If you are suspecting the MTU, make the MTU value to 1492 and try. as well as Sonicwall have his on tool to check the matching MTU.
Navigate to System-->Diagnostics-->Diagnostic Tool--> Select the PMTU Discovery.
1452 may not be the most optimal for your ISP, and different KB articles provide different values.
Does your ISP have a published recommendation? If not, you'll have to determine that on your own.
Are all the sites static IP with ISP device in bridge mode?
Hello,
Are you able to see anything else at the firewall log?
What about the logs from the other end?
Kind regards,
Sebastián Yáñez
Solutions Engineer, EMEA Team
To Check if a VPN connection is up, don't look at the green bols/led. Go to the Active tunnel page.
The geen bols/led have a bug in the gen7 and will not always show a connection.
No green bols/led
Connections up.
Finally, the fixed the green VPN bols/led in firmware SonicOS 7.0.1-5080
Just an update on this PPPoE issue. I gave up trying to use the SonicWALL to directly authenticate the PPPoE session. I just have nothing but problems with this. Instead, I set the SonicWALL WAN interface IP to a static private address (Preferably one that doesn't conflict with your enterprise LAN). Then, I use the ISP provided modem to authenticate the PPPoE connection. In most cases this ISP provided device is also a NAT router/firewall. I use it to create a 1:1 NAT sending all inbound traffic to the SonicWALL static WAN interface IP.
I'm not usually a fan of double NAT'ing like this, but it is reliable and solved the problem. Only catch is that you have to be sure to set an IKE ID when configuring tunnels. It will select the private WAN interface IP if you leave that field blank and your tunnel won't come up.
Regards,
Adam Tyler
You could also just set the ISP provided modem to bridge mode. Any DSL/PPPoE connection I've ever had to do with a Sonicwall I've simply used the ISP modem in bridge mode and static'd the Sonicwall. It's better than a double NAT.
The original problem was a result of running the ISP modem in bridge mode with the SonicWALL handling PPPoE authentication.
Regards,
Adam Tyler
I did not say in my situation the Sonicwall was doing PPPoE.
Lol, then why comment on this thread? The root issue description is specific to PPPoE. No need to respond to this.
I guess I will just avoid your threads.