> sizes up to 1492 (ping -s 1464 x.x.x.x), but not with packet sizes > over. I can't figure out why, but I suspect that ping sets the DF > flag.
Ping does set the DF flag bit, so you're hitting the MTU limit of your PPPoE link.
Okay - so why does ping do that? Is there a reason for this - it confuses diagnostics I'd think.
It would be even more confusing if ping requests/replies got fragmented, if you think about it (what would happen if only part of a fragment got to the other end?).
> Hope one of you gurus can help.
I don't have a clear picture of your network topology, but it
ClientLan---FW1---<PPPoE,1492>---ISP---internet---ISP---<ethernet,1500>- --FW2---ServerLan
FW1 has VPN link to FW2 with MTU 1350
you're running into two different MTU problems. The limited MTU of your PPPoE link (which it sounds like you have solved), and the
Yes, I'd like to think so too.
MTU of your IPSec link (which may or may not be going over the PPPoE connection for an additional "haircut"...that part isn't clear from the above).
Uhmm, there aren't any problems on the VPN link internally. Everything works fine from/to ClientLan and ServerLan.
It's when doing the SNAT things are fouled up.
A client wants to do a HTTP connection to FW1's external IP. This is SNAT'ed to a server on ServerLan, so the server sees the request as coming from ClientLan (the only way the routing back to the client could be made to work). So the packet arrives at FW1, which changes the source to a ClientLan address and the destination to a ServerLan address and pumps it down the VPN tunnel. The problem is that large packets never get through to the other end, because they're too large for either the IPSEC og PPPoE link.
It seems like packets from the internet that don't fit down your IPSec pipe aren't properly getting ICMP messages back to the sender (ie PMTU discovery is broken for the specific case of inbound PPPoE traffic that heads back out the IPSec link).
Bingo.
Provide a diagram of how your network is setup, and maybe I (or someone else) will have some ideas on how to get things working properly.
I was hoping to hear from you, as you seem to have great insight on networking on this list. Thanks for responding.
My first suggestion is to use the public IP of FW2 (the serverlan firewall) rather than FW1 (the privatelan firewall) for your public services. As constructed, you're running public traffic across your PPPoE link twice, as well as doubling up on tunneling protocols (IPSec wrapped inside PPPoE).
If you have to keep things the way they are for some reason, it sounds like the ICMP error messages created when a large packet comes in from the internet to FW1 and gets routed down the VPN either aren't getting generated, or are going to the wrong place.
A packet sniffer might be of some help with solving this problem. You can compare the traces of working and non-working pings from the internet to your SNAT'd server.
If you continue to have problems, I might be able to help if you provide a full dump of your firewall rules, routing tables, and interface setup, but you'll probably need someone more familiar with Bering, IPTables, and shorewall (I'm still stuck in the 2.2 kernel era with Dachstein and IPChains).
-- Charles Steinkuehler [EMAIL PROTECTED]
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
