[leaf-user] HELP...
Hello List.. It is the first time that I write. I am of Argentinean and my English is not good.. Am I to install WISP and did he/she want to know if he/she already has incorporate the possibility to use DHCp..? Thank you.. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
Charles S. wrote: I understand your logic, but what are you doing that kills the connection? You should be able to play with IPSec tunnels all day long w/o messing up the main external uplink... Some of the changes I tried were tweaking the CLAMPMSS in shorewall and CLAMPMSS and mtu setting in PPPoE. Those are the settings that either required the reboot (since I'm doing this remote) or sometimes locked my remote connection out. The headache was when I then needed someone local to undo my last change and reboot to alow me back in, which meant I had to do it when someone was in the office as opposed to late an night (when I do my best work anyway ;) ) I can play with the tunnels all day, but he only parameter I've played with there is overridemtu. I'd sniff your traffic first. If your problem is caused by large packets getting sent with the don't fragment option set, *NOTHING* is going to help you get that traffic across your VPN, unless you change something fundamental (ie change the traffic itself by fixing the machine(s) generating the large packets, or switch to a type of tunneling that can hide the fragmentation). I missed an earlier question about what kind of traffic am as having trouble with. After the VPN was established and I thought everything was good I tried the following (since at 1st I didn't know if it was Windoze secrurity, name resolution, routing, et.) - I successfully mapped a Windoze share (champagne corks flew), but it would hang when I tried to get a directory listing - I tired to view a web site on the distant end and the browser resolved it and loaded part of the page, but then hung - I successfully opened an tp connection to a server at the remote end, got a diectory listing, transferred a tiny file (txt doc with about 5 characters in it), tried to transfer a larger file (maybe 5kb) and the transfer hung. - And as I mentioned before, vpn traffic from the remote side to local servers works like a charm. If you don't know *WHY* this one site is causing you fits, you won't know if a hardware box will fix it. I was just hoping there was a good chance of resolving the problem by just throwing money at it (or at least through Netopia's tech support at it, which I have been pleasantly surpised by in their knowledge) Also, as mentioned before, once you sniff the traffic and actually *SEE* what's going on (rather than speculating), I'm pretty sure a solution will present itself. I'm on it, thanks for pushing me forward as I fell into a semi-rank. - Todd --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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
Re: [leaf-user] My Dachstein not quite up and running
Chris Low wrote: EXTERN_TCP_PORTS=0/0_25 to allow anyone on the internet to send you e-mail, and you'll probably have a lot better luck. Did it and still not receiving. Also tried Mike's suggestion to remove the $ from INTERN_SERVERS=tcp_$192.168.1.2_smtp_10.10.10.200_smtp. Backed up the firewall and rebooted, still nothing. output from netstat -nr still looks the same Um...not quite the same. This time you have packets matching your rule allowing inbound mail: 19 936 ACCEPT tcp -- 0xFF 0x00 eth0 0.0 .0.0/00.0.0.0/0 * - 25 From the information you posted, I can't tell if your port-forwarding is setup correctly. Please run net ipfilter list, which outputs port-forwarding information after the ipchains info. It was only on for about an hour--just long enough to set everything up and test it out. Since the server is live I can only make changes to it when the office is empty or it'll disrupt the workflow. What does it mean to update the MX records? MX records are the DNS entries that tell remote systems how to contact your mail server (as opposed to A records, which match system names to IP addresses). If you don't have an MX record tying your domain name to the IP of your mail server, you won't get mail from the internet at large. Note that this doesn't mean you won't get mail...your MX records could point somewhere else (like your ISP or the registrar for your domain name), and that system could forward mail to you. This looks OK, assuming 208.57.0.10 is your ISP's DNS server. The domain-name-servers option should be 10.10.10.254 if you want to use DNSCache. Note that you are only providing one DNS server to your dhcp clients, while in the network.conf settings above you have a primary and secondary entry. If the 208.57.0.10 machine is not working properly, your firewall (and any other systems with both DNS IP's) will automatically use the other system, while machines configured via dhcp will simply fail. I'm assuming this is a space separated list so to add the secondary DNS server it'll be something like: option domain-name-servers 208.57.0.10 208.57.0.11; Actally, you need to seperate entries with commas: option domain-name-servers 208.57.0.10, 208.57.0.11; See the dhcpd man pages for details: http://leaf.steinkuehler.net/devel/cstein/Packages/dhcpd.htm http://leaf.steinkuehler.net/devel/cstein/Packages/man/dhcpd.conf.5.man.htm http://leaf.steinkuehler.net/devel/cstein/Packages/man/dhcp-options.5.man.htm -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 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
Re: [leaf-user] DS2.2.20 + FS1.99 + WIN2K = Tunnelled but can't ping
Victor B. Berdin wrote: Hello everyone, I've upgraded my DS 2.2.19 to 2.2.20 and built the current FSwan1.99 with x509 to my kernel. Everything works fine if I were to use FSwan to FSwan Sub2Sub VPN (either by PSK or RSA/Certs). My problem is that, when I InterOp my LRP machine to a WIN2K, a tunnel gets formed, but it seems that it dies down (the active tunnel / association in ipsecmon disappears) after a few minutes. And to top it all, I can't ping from either subnet. It's not really a LEAF problem as everything works perfectly using a FSwan to FSwan setup. I believe the problem lies on my WIN2K side. I'm just hoping someone here will be kind enough to shed any hints concerning M$ WIN2K. Anyways, here's what I have on my WIN2K: Security Method: Negotiate Security Session Key PFS Custom MD5 3DES snip I guess this is all OK, I don't really know that much about setting up IPSec on windows boxen. The one thing I can point out is the 3DES entry. IIRC, you have to install a patch to Win2K to be able to run 3DES, even though the check-box is there regardless. FreeS/WAN will *NOT* talk 1DES if the 2K system is not patched to really do 3DES. I doubt this is a problem based on the output of ipsec look provided below. And here's my ipsec.conf: config setup interfaces=%defaultroute plutodebug=none klipsdebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default keyingtries=0 pfs=yes conn SR3K-NET authby=secret left=192.168.3.1 leftsubnet=192.168.246.0/24 leftnexthop=192.168.3.200 right=192.168.2.1 rightsubnet=192.168.0.0/24 rightnexthop=192.168.2.200 auto=start This looks OK except possibly for your connection description. It looks like your trying to create a subnet-subnet tunnel. In Microsoft world, this is only possible with 2K-Server or maybe 2K-Advanced Server, as part of the we want *ALL* the money campaign. If you're running 2K-Workstation, I don't think this will *EVER* work using microsoft's client (I think you can buy the ssh-sentinel client or similar and get subnet-subnet connectivity at a much lower price than upgrading to Server or Advacned Server). The output of my ipsec look: SR3K Wed Feb 12 20:11:41 UTC 2003 192.168.246.0/24 - 192.168.0.0/24 = [EMAIL PROTECTED] [EMAIL PROTECTED] (0) [EMAIL PROTECTED] ESP_3DES_HMAC_MD5: dir=out src=192.168.3.1 iv_bits=64bits iv=0x0e86cc9dda1e8d8a ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(12,0,0) [EMAIL PROTECTED] ESP_3DES_HMAC_MD5: dir=in src=192.168.2.1 iv_bits=64bits iv=0x5488aa183793c623 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(12,0,0) [EMAIL PROTECTED] IPIP: dir=in src=192.168.2.1 life(c,s,h)=addtime(12,0,0) [EMAIL PROTECTED] IPIP: dir=out src=192.168.3.1 life(c,s,h)=addtime(12,0,0) DestinationGateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.3.200 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 192.168.3.200 255.255.255.0 UG 0 0 0 ipsec0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 Since it looks like the two ends negotiated an SA, I don't think you're encountering the 1DES/3DES patch problem. Also: - My WIN2K eth0 is sharing it's internet resource with eth1. Thus, eth1 automatically inheriting the 192.168.0.0/24 network - pinging from WIN2K N-times, simply displays the Negotiating IP Security message. pinging from its client to the client on the other end is negative. - I'll be glad to send more command results if needed. The FreeS/WAN side logs (in /var/log/auth.log) are always helpful, and the equivelent logs from the windows side (wherever they live) would also be good to review. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] Follow Up To: DS2.2.20+FS1.99+WIN2K = Tunnelled butcan't ping
Victor B. Berdin wrote: Hello everyone, ...and here are snips from my barf, wherein the last 2 lines of my auth.log suggests a known problem with WIN2K being able to operate using 3DES, then secretly revert to 1DES as discussed in this link: http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00151.html. But I'm under the impression that this only happens if I hadn't installed SP2. Actually I've installed SP3 along with ALL other patches available for my WIN2K machine as recommended by Win Update. As mentioned before, I don't think this is your problem, or you wouldn't be negotiating an SA. I'd be more concerned about the last log message, where FreeS/WAN is ignoring something from the windows box...you might have some incompatible feature enabled, or required feature disabled on the windows side. Any hints as to what else I can try out to fix this? Using third party tools such as ssh sentinel (w/c looks very promising) or pgpnet is currently not an option (as these are commercial wares). Have you been to any of the windows FreeS/WAN interop sites where they post HOWTO's for getting windows IPSec setup properly? Read through the interop docs on the FreeS/WAN site? And btw, is l2tp a stable alternative to this? Along with l2tpd in Linux? Any comments about l2tp? l2tp is *NOT* a vpn protocol. It is a protocol to bridge two remote networks at the wire level (Level 2 tunneling protocol), allowing Microsoft to send broadcast packets across a WAN that is typically tunneled inside a VPN protocol (like ipsec). I suggest staying away from l2tp unless absolutely required. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
[leaf-user] Bering Ramdisk sizes
How do I allocate more space to the /dev/root ram disk? Filesystem 1k-blocks Used Available Use% Mounted on /dev/root 6144 607272 99% / tmpfs1525616 15240 0% /tmp tmpfs 2048 300 1748 15% /var/log /dev/hda 21536 21536 0 100% /cdmnt Here's what is filling up the space. Ezipupd is the only expendible one and I image it won't free up much space. NameVersionDescription ===-==-= = initrd V1.0-stable rootV1.0-stable etc V1.0-stable log V1.0-stable local V1.0-stableLocal package. This package does not contain a modules V1.0-stableModules package. Contains kernel modules and u iptables1.2.6a iptables weblet 1.2.0 weblet - LRP status via a small web server shorwall1.3.13 Shoreline Firewall (Shorewall) mawk1.3.3 libz1.1.4 zlib compression library. Needed for openssh sshd3.5p1 OpenSSH sshd daemon. dhcpd 2.0pl5 dhcpd - Autoconfigure client machines dnscache1.05a dnscache from djbdns (V1.05a) package creates ppp 2.4.1-pppoePPPd Deamon pppoe 3.3-1 pppoe add-on for pppd ipsec5091.99 Freeswan IPSEC patched for X509 support ezipupd 3.0.11b7 ez-ipupdate is a client for several dynamic IP Thanks, Todd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
AW: [leaf-user] Bering Ramdisk sizes
How do I allocate more space to the /dev/root ram disk? The syst_size Parameter to the kernel, as described in the docs add it to the kernel start line in syslinux.cfg linux ... PKGPATH=/dev/hdc1 syst_size=20M ... etc. - Alex --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] Bering Ramdisk sizes
Thanks a ton!! I'd searched all over, but apparently not in the right places. - Todd -Original Message- From: Alex Rhomberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 10:20 AM To: Todd Pearsall; [EMAIL PROTECTED] Subject: AW: [leaf-user] Bering Ramdisk sizes How do I allocate more space to the /dev/root ram disk? The syst_size Parameter to the kernel, as described in the docs add it to the kernel start line in syslinux.cfg linux ... PKGPATH=/dev/hdc1 syst_size=20M ... etc. - Alex --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] Bering/Shorewall vs. Dachstein
On Wednesday 12 February 2003 10:44 pm, Tom Eastep wrote: snip Here is the connection tracking table: udp 17 177 src=192.168.1.1 dst=12.77.140.250 sport=1347 dport=1193 src=12.77.140.250 dst=12.243.227.207 sport=1193 dport=1347 [ASSURED] use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1348 dport=1039 src=12.77.140.250 dst=12.243.227.207 sport=1039 dport=1348 [ASSURED] use=1 udp 17 18 src=10.175.0.1 dst=255.255.255.255 sport=67 dport=68 [UNREPLIED] src=255.255.255.255 dst=10.175.0.1 sport=68 dport=67 use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1037 dport=1194 src=12.77.140.250 dst=12.243.227.207 sport=1194 dport=1037 [ASSURED] use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1349 dport=1040 src=12.77.140.250 dst=12.243.227.207 sport=1040 dport=1349 [ASSURED] use=1 tcp 6 431989 ESTABLISHED src=192.168.1.1 dst=216.187.103.211 sport=1304 dport=5501 src=216.187.103.211 dst=12.243.227.207 sport=5501 dport=1304 [ASSURED] use=1 udp 17 179 src=192.168.1.1 dst=12.77.140.250 sport=1038 dport=1195 src=12.77.140.250 dst=12.243.227.207 sport=1195 dport=1038 [ASSURED] use=1 The ICMP 11,0 packets in the log are explained by the third entry which suggests that the culprit is a DHCP client using an RFC 1918 source address. 216.187.103.211 is chat.eyeball.com - the EyeBall Chat server. Sean's IP address is 12.243.227.207 and 12.77.140.250 is Mom's IP address. So: a) The Magic Technology worked without any races on Sean's end (we didn't see any denied packets). b) The 5 UDP connections between Sean and Mom are as described in the EyeBall documentation. c) Sean -- is the AOL subscriber that you mention able to connect with EyeBall users other than yourself? I think most, if not all, of AOL services are proxy'ed and likely VPN'ed as well the last time I looked. I know a lot of services are not working as advertised on AOL, especially when the connection is to the internet at-large. Maybe their proxy messes this up. I would still like to get your tcpdump capture Sean to see if Ray's conjecture is correct. I would to. It would be quite interesting to see how the connection is setup initally w/o port-fw'ing. It's not breaking in the NAT ports, so this must be application specific, especially with use of TCP . Very interesting! ;-) Thanks, -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] It Works!!
On Wednesday 12 February 2003 07:24 pm, David Pitts wrote: Lynn, maybe you mean me, not 'Dan'?? Anyway, I was/am using a Bering stable 1.0 with ezipupdt.lrp and BPALogin.lrp. I deleted some packages I didn't need like bridge.lrp, keyboard.lrp, ppp.lrp and pppoe.lrp. I also had pump and dhcpd out when I was playing with uDHCP. Sorry about the wrong name there David brainfart, I have a co-worker named Dan Pitts and I guess I get confused sometimes. ;-) Thanks for the information, further you have added ipsec correct? Have you changed the internal subnet from 1922.168.1.0? -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
[leaf-user] Cisco VPN client through (Dachstein) LRP
I have been trying (unsucessfuly) to connect to a VPN server using Cisco VPN client version 3.5.1 (B). The VPN client is running on win98 machine which is networked to a Dachstein LRP box. I have found a series of e-mails in the archive from Rob Fegley dated 21 Dec 2002. Among the replies to this email is one from Colin Helliwell detailing his successful efforts by loading ip_masq_ipsec module, opening UDP 500 to the servers IP, and implementing EXTERN_PROTO0=50... and EXTERN_PROTO1=47... I have tried this and it does not work for me. My VPN log shows three attempts to send IKE, then quits without any transfer. I know that the IP address of the server is correct. I suspect that the firewall is not allowing the transfer to take place. However, I do find a udp 500 connection to the server IP in the masqued connections list using Weblet. I was wondering if there is some simple way of disabling the firewall completely for traffic to the specific IP of the VPN server and seeing what shows up in the logs. Would this be a good way to trouble shoot this problem or is there a better way. Any help or suggestions would be appreciated. Thanks, Frank Kamp --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] Cisco VPN client through (Dachstein) LRP
On Thursday 13 February 2003 09:55 am, [EMAIL PROTECTED] wrote: I have been trying (unsucessfuly) to connect to a VPN server using Cisco VPN client version 3.5.1 (B). The VPN client is running on win98 machine which is networked to a Dachstein LRP box. I have found a series of e-mails in the archive from Rob Fegley dated 21 Dec 2002. Among the replies to this email is one from Colin Helliwell detailing his successful efforts by loading ip_masq_ipsec module, opening UDP 500 to the servers IP, and implementing EXTERN_PROTO0=50... and EXTERN_PROTO1=47... You also need to port-forward udp 500 to the Win98 client. This will require loading the ip_masq_portfw module as well. You are running a 'pass-through' type connection, refer to: http://leaf-sourceforge.net/devel/guitarlynn/ipsec.txt -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] Cisco VPN client through (Dachstein) LRP
[EMAIL PROTECTED] wrote: I have been trying (unsucessfuly) to connect to a VPN server using Cisco VPN client version 3.5.1 (B). The VPN client is running on win98 machine which is networked to a Dachstein LRP box. I have found a series of e-mails in the archive from Rob Fegley dated 21 Dec 2002. Among the replies to this email is one from Colin Helliwell detailing his successful efforts by loading ip_masq_ipsec module, opening UDP 500 to the servers IP, and implementing EXTERN_PROTO0=50... and EXTERN_PROTO1=47... I have tried this and it does not work for me. My VPN log shows three attempts to send IKE, then quits without any transfer. I know that the IP address of the server is correct. I suspect that the firewall is not allowing the transfer to take place. However, I do find a udp 500 connection to the server IP in the masqued connections list using Weblet. I was wondering if there is some simple way of disabling the firewall completely for traffic to the specific IP of the VPN server and seeing what shows up in the logs. Would this be a good way to trouble shoot this problem or is there a better way. There is a simple way to do this...run: ipchains -I input -j ACCEPT -s Remote IP -i external interface This will allow all traffic from the Remote IP through the firewall. To remove the rule when done testing, either re-load your firewall rules (net ipfilter reload), or simply manually delete the rule (type exactly the same ipchains command as above, but replace the -I (insert) with -D (delete)). Also, which version of Dachstein are you using? The CD-ROM comes with a kernel compiled to run IPSec on the firewall, which is reportedtly incompatible with using the IPSec masquerading helper module. The floppy-disk versions of Dachstein come with the proper kernel for masquerading IPSec, but you do have to configure the module to load. Troubleshooting: - Make sure the ipsec masquerading module is loaded with the lsmod command. - Review the output of net ipfilter list, and verify the proper UDP ports are opened. Look for non-zero byte/packet counts next to deny or reject rules, and check your firewall logs (/var/log/messages) for any indications of dropped traffic. - If possible, check the logs on the remote end. This will tell you if your packets are getting dropped between your system and the far end, or if the far end is ignoring you for some reason (invalid authentication credentials, unknown connection description, far-end firewall rules, etc). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
On Thursday 13 February 2003 08:15 am, Todd Pearsall wrote: - I successfully mapped a Windoze share (champagne corks flew), but it would hang when I tried to get a directory listing - I tired to view a web site on the distant end and the browser resolved it and loaded part of the page, but then hung - I successfully opened an tp connection to a server at the remote end, got a diectory listing, transferred a tiny file (txt doc with about 5 characters in it), tried to transfer a larger file (maybe 5kb) and the transfer hung. - And as I mentioned before, vpn traffic from the remote side to local servers works like a charm. Ok, let's look at the base of you connection. The remote end works flawlessly when connecting to your subnet, correct? On your subnet, you can map a share but transfers generally bomb out, correct? I'll bet my desktop that your running Win2k/XP Pro/Server on the local end AND not on the remote end. If so, you can thank Bill G. for breaking the DNS and WINS rfc's for your problem.The integration of these two services in the latter M$ enterprise releases have caused many admins (myself included) to beat themselves in the head with a hammer. Generally, mapping the drives fixes this problem (to some degree). Is my guess in the ballpark? -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
Ok, let's look at the base of you connection. The remote end works flawlessly when connecting to your subnet, correct? Yup On your subnet, you can map a share but transfers generally bomb out, correct? The local end can map a share, but transfers hang. Ftp connect, transfers hang, etc. I'll bet my desktop that your running Win2k/XP Pro/Server on the local end AND not on the remote end. If so, you can thank Bill G. for breaking the DNS and WINS rfc's for your problem.The integration of these two services in the latter M$ enterprise releases have caused many admins (myself included) to beat themselves in the head with a hammer. Generally, mapping the drives fixes this problem (to some degree). Is my guess in the ballpark? You're close, except it's Windoze at both ends. Doesn't work: Local WinXP to Remote WinNT Server Works: Remote WinXP to Local Win2000 Server While I'm at it, do I want the tcpdump for eth1 or ipsec0 (I assume not ppp0 since it's all encrypted, but wasn't sure.) Another note I wanted to repeat just in case it was important and overlooked in my 1st message of this lengthy thread. When I restart PPPoE (locally), in the course of the connection establishing I get messages to the effect of Cant't increase MTU to 1500 serveral times. That may not be the exact message, because I can't see it in the logs when I reboot the router remotely. Thanks for all the support. - Todd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
On Thursday 13 February 2003 10:58 am, Todd Pearsall wrote: I'll bet my desktop that your running Win2k/XP Pro/Server on the local end AND not on the remote end. If so, you can thank Bill G. for breaking the DNS and WINS rfc's for your problem.The integration of these two services in the latter M$ enterprise releases have caused many admins (myself included) to beat themselves in the head with a hammer. Generally, mapping the drives fixes this problem (to some degree). Is my guess in the ballpark? You're close, except it's Windoze at both ends. Doesn't work: Local WinXP to Remote WinNT Server Works: Remote WinXP to Local Win2000 Server What's running DNS service on either/both networks? Another quick test connect a *NIX/Samba work station, a Win 98/ME, or a Win2k/XP 'Home edition box to your local network and attempt a transfer across the tunnel. I think this is a M$ DNS problem. While I'm at it, do I want the tcpdump for eth1 or ipsec0 (I assume not ppp0 since it's all encrypted, but wasn't sure.) The tunnel isn't run through eth1, you'll need to use ipsec0/ Another note I wanted to repeat just in case it was important and overlooked in my 1st message of this lengthy thread. When I restart PPPoE (locally), in the course of the connection establishing I get messages to the effect of Cant't increase MTU to 1500 serveral times. That may not be the exact message, because I can't see it in the logs when I reboot the router remotely. That's probably because xDSL uses a MTU of 1492 to account for encryption latency. -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
Todd Pearsall wrote: You're close, except it's Windoze at both ends. Doesn't work: Local WinXP to Remote WinNT Server Works: Remote WinXP to Local Win2000 Server Check into this at some of the MS FAQ sites. I think there are some issues when connecting XP to NT4 servers (XP machines can't be added to NT domains or something like that)...part of the MS forced upgrade strategy. IIRC, you can get it to work, but you have to be very careful about how you set everything up. You could test this with an XP and NT box sitting across a router from each other, then try to make things work across the VPN. While I'm at it, do I want the tcpdump for eth1 or ipsec0 (I assume not ppp0 since it's all encrypted, but wasn't sure.) Another note I wanted to repeat just in case it was important and overlooked in my 1st message of this lengthy thread. When I restart PPPoE (locally), in the course of the connection establishing I get messages to the effect of Cant't increase MTU to 1500 serveral times. That may not be the exact message, because I can't see it in the logs when I reboot the router remotely. It depends on exactly what you're trying to see, but I'd start with your internal interface. Earlier versions of tcpdump don't deal well with the virtual ipsec interface, and there's also the confusion of the whole ethernet + PPPoE + IPSec layer upon layer of interfaces/protocols. If your VPN is working properly, watching what goes in and out the local interface should tell you everything you need to know (especially if you can do this on both ends). If any packets disappear between the ends (without ICMP errors or similar), you'll know you have to look at the VPN or PPPoE setup. BTW: Do any of your other locations use PPPoE, or just the broken one? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
Todd Pearsall [EMAIL PROTECTED] schrieb: Another note I wanted to repeat just in case it was important and overlooked in my 1st message of this lengthy thread. When I restart PPPoE (locally), in the course of the connection establishing I get messages to the effect of Cant't increase MTU to 1500 serveral times. That may not be the exact message, because I can't see it in the logs when I reboot the router remotely. Did you tried this one after the connection is up? YOu can also try smaller values. ip link set ppp0 mtu 1472 Cu -- Lars Kneschke http://www.kneschke.de written with FeLaMiMail --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] HELP...
Welcome to the list. People are nice here, and we'll try to take the time to get your system running. I have not used WISP, so you will have to wait for a specific answer to your question. Most people use Bering rather than WISP, and you might try it yourself. There might be more documents written to help you on our website. What do you want to do with your LEAF box? What is your network layout? Take care, Matthew Soporte Tecnico Internueve S.R.L wrote: Hello List.. It is the first time that I write. I am of Argentinean and my English is not good.. Am I to install WISP and did he/she want to know if he/she already has incorporate the possibility to use DHCp..? Thank you.. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
On Thu, 2003-02-13 at 09:35, Charles Steinkuehler wrote: Todd Pearsall wrote: You're close, except it's Windoze at both ends. Doesn't work: Local WinXP to Remote WinNT Server Works: Remote WinXP to Local Win2000 Server Check into this at some of the MS FAQ sites. I think there are some issues when connecting XP to NT4 servers (XP machines can't be added to NT domains or something like that)...part of the MS forced upgrade strategy. IIRC, you can get it to work, but you have to be very careful about how you set everything up. You could test this with an XP and NT box sitting across a router from each other, then try to make things work across the VPN. Actually XPPro boxen can join an NT4 PDC. I recently migrated a bunch of XP and NT4 workstations from an NT PDC to a Samba PDC. Ugly job! Stephen --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
Check into this at some of the MS FAQ sites. I think there are some issues when connecting XP to NT4 servers (XP machines can't be added to NT domains or something like that)...part of the MS forced upgrade strategy. IIRC, you can get it to work, but you have to be very careful about how you set everything up. You could test this with an XP and NT box sitting across a router from each other, then try to make things work across the VPN. Once I get any traffic moving I'm better prepared to fight the MS stuff. That's why I'm using ftp as my test (how bad can M$ mess that up?) BTW: Do any of your other locations use PPPoE, or just the broken one? Yup, I have 1 DSL PPPoE, 3 on cable modems, 1 off ethernet connected to a T1. These have gateway FreeSWAN VPNs between them plus IPSEC VPNs to a Cisco concentrator and a Netopia R7200. That's what's making me so nuts. I told this office I'd come down a knock it out one day while I was there for other stuff. I even configured one in my local office, mail it and it was plug-and-plug on the net AND the VPN!! I thought I was pretty good at this and this damn connection has humbled me. Thanks again. - Todd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
On Thursday 13 February 2003 01:44 pm, Todd Pearsall wrote: Once I get any traffic moving I'm better prepared to fight the MS stuff. That's why I'm using ftp as my test (how bad can M$ mess that up?) Real bad if your using a Win2K/XP Pro workstation. When 2K first came out I added a couple of workstations to an existing NT Domain. I had so many problems like you are describing that I ended up throwing the Disks and licenses in the trash. It might be worth your time to read the submitted new rfc's for DNS and WINS that M$ has implemented with the newest OS's. Most companies would get the rfc's passed before forcing them on everyone. -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
Below are tcpdumps from the eth1 and then the ipsec0 interfaces. Any help in making some sense would be great. Let me know if other options, test, etc. would be more useful. If it gets too wrapped in e-mail I can make it available on the web. Thanks. - Todd User on the local end makes a FTP connection remote server These dumps include the user performing an 'ls' on a small directory and then a 'get' for a file. The get hangs and eventually times out. # tcpdump -n -i eth1 net 172.30.85.0 mask 255.255.255.0 tcpdump: listening on eth1 15:13:02.074186 192.168.5.13.4426 172.30.85.100.21: P 2956246103:2956246129(26) ack 3802495246 win 63620 (DF) 15:13:02.124191 172.30.85.100.21 192.168.5.13.4426: P 1:31(30) ack 26 win 8097 (DF) [tos 0x10] 15:13:02.125986 192.168.5.13.4426 172.30.85.100.21: P 26:32(6) ack 31 win 63590 (DF) 15:13:02.173530 172.30.85.100.21 192.168.5.13.4426: P 31:86(55) ack 32 win 8091 (DF) [tos 0x10] 15:13:02.174757 172.30.85.100.20 192.168.5.13.4455: S 3935752456:3935752456(0) win 8192 mss 1460 (DF) [tos 0x8] 15:13:02.175289 192.168.5.13.4455 172.30.85.100.20: S 3101694541:3101694541(0) ack 3935752457 win 64240 mss 1460 (DF) 15:13:02.220662 172.30.85.100.20 192.168.5.13.4455: . ack 1 win 8760 (DF) [tos 0x8] 15:13:02.226166 172.30.85.100.20 192.168.5.13.4455: P 1:198(197) ack 1 win 8760 (DF) [tos 0x8] 15:13:02.227301 172.30.85.100.20 192.168.5.13.4455: F 198:198(0) ack 1 win 8760 (DF) [tos 0x8] 15:13:02.227845 192.168.5.13.4455 172.30.85.100.20: . ack 199 win 64043 (DF) 15:13:02.228102 192.168.5.13.4455 172.30.85.100.20: F 1:1(0) ack 199 win 64043 (DF) 15:13:02.278985 172.30.85.100.20 192.168.5.13.4455: . ack 2 win 8760 (DF) [tos 0x8] 15:13:02.363486 192.168.5.13.4426 172.30.85.100.21: . ack 86 win 63535 (DF) 15:13:02.411919 172.30.85.100.21 192.168.5.13.4426: P 86:110(24) ack 32 win 8091 (DF) [tos 0x10] 15:13:02.564014 192.168.5.13.4426 172.30.85.100.21: . ack 110 win 63511 (DF) Started 15:13:05.649139 192.168.5.13.4426 172.30.85.100.21: P 32:58(26) ack 110 win 63511 (DF) 15:13:05.698309 172.30.85.100.21 192.168.5.13.4426: P 110:140(30) ack 58 win 8065 (DF) [tos 0x10] 15:13:05.700220 192.168.5.13.4426 172.30.85.100.21: P 58:85(27) ack 140 win 63481 (DF) 15:13:05.753633 172.30.85.100.21 192.168.5.13.4426: P 140:222(82) ack 85 win 8038 (DF) [tos 0x10] 15:13:05.754897 172.30.85.100.20 192.168.5.13.4456: S 3936638977:3936638977(0) win 8192 mss 1460 (DF) [tos 0x8] 15:13:05.755417 192.168.5.13.4456 172.30.85.100.20: S 3102618198:3102618198(0) ack 3936638978 win 64240 mss 1460 (DF) 15:13:05.775398 192.168.5.13.4426 172.30.85.100.21: . ack 222 win 63399 (DF) 15:13:05.802418 172.30.85.100.20 192.168.5.13.4456: . ack 1 win 8760 (DF) [tos 0x8] # tcpdump -n -i ipsec0 tcpdump: listening on ipsec0 15:13:42.267262 192.168.5.13.4426 172.30.85.100.21: P 2956246198:2956246224(26) ack 3802495539 win 63327 (DF) [tos 0x10] 15:13:42.314472 65.120.71.240 69.0.0.90: 65.81.136.33 69.16.0.70: (frag 12804:4294967276@1288+) [tos 0x24] (ipip) 15:13:42.317751 192.168.5.13.4426 172.30.85.100.21: P 26:32(6) ack 31 win 63297 (DF) [tos 0x10] 15:13:42.363794 65.120.71.240 69.0.0.115: 65.81.136.33 69.16.0.95: (frag 12804:4294967236@46128) [tos 0x26,ECT] (ipip) 15:13:42.364713 65.120.71.240 69.0.0.64: 65.81.136.33 69.8.0.44: (frag 12804:4294967264@27904+) [tos 0x40] (ipip) 15:13:42.367335 192.168.5.13.4458 172.30.85.100.20: S 3111798723:3111798723(0) ack 3945068591 win 64240 mss 1460 (DF) [tos 0x8] 15:13:42.411530 65.120.71.240 69.0.0.60: 65.81.136.33 69.8.0.40: (frag 12804:4294967260@58880+) [tos 0x23,ECT,CE] (ipip) 15:13:42.416740 65.120.71.240 69.0.1.1: 65.81.136.33 69.8.0.237: (frag 12804:4294967276@64904+) [tos 0x6d] (ipip) 15:13:42.417202 65.120.71.240 69.0.0.60: 65.81.136.33 69.8.0.40: (frag 12804:4294967292@42040+) [tos 0x5d] (ipip) 15:13:42.420616 192.168.5.13.4458 172.30.85.100.20: . ack 199 win 64043 (DF) [tos 0x8] 15:13:42.421869 192.168.5.13.4458 172.30.85.100.20: F 1:1(0) ack 199 win 64043 (DF) [tos 0x8] 15:13:42.470904 65.120.71.240 69.0.0.60: 65.81.136.33 69.8.0.40: (frag 12804:4294967248@20024+) [tos 0x1d] (ipip) 15:13:42.504877 192.168.5.13.4426 172.30.85.100.21: . ack 86 win 63242 (DF) [tos 0x10] 15:13:42.550281 65.120.71.240 69.0.0.84: 65.81.136.33 69.16.0.64: (frag 12804:4294967256@23448+) [tos 0x59] (ipip) 15:13:42.705588 192.168.5.13.4426 172.30.85.100.21: . ack 110 win 63218 (DF) [tos 0x10] 15:13:45.116832 192.168.5.13.4426 172.30.85.100.21: P 32:58(26) ack 110 win 63218 (DF) [tos 0x10] 15:13:45.215011 65.120.71.240 69.0.0.90: 65.81.136.33 69.16.0.70: (frag 12804:4294967244@17136+) [tos 0x67,ECT,CE] (ipip) 15:13:45.218377 192.168.5.13.4426 172.30.85.100.21: P 58:85(27) ack 140 win 63188 (DF) [tos 0x10] 15:13:45.270053 65.120.71.240 69.0.0.142: 65.81.136.33 69.16.0.122: (frag 12804:4294967260@58032) [tos 0x3c] (ipip) 15:13:45.270918 65.120.71.240 69.0.0.64: 65.81.136.33 69.8.0.44: (frag 12804:4294967260@25792) [tos 0x47,ECT,CE]
Re: [leaf-user] PPPoE, IPSec and MTU size problems
Todd Pearsall wrote: Once I get any traffic moving I'm better prepared to fight the MS stuff. That's why I'm using ftp as my test (how bad can M$ mess that up?) Now there's a baited question. I'll keep my response civil, and point out that that's what your traffic sniffer is for. :) BTW: Do any of your other locations use PPPoE, or just the broken one? Yup, I have 1 DSL PPPoE, 3 on cable modems, 1 off ethernet connected to a T1. These have gateway FreeSWAN VPNs between them plus IPSEC VPNs to a Cisco concentrator and a Netopia R7200. That's what's making me so nuts. I told this office I'd come down a knock it out one day while I was there for other stuff. I even configured one in my local office, mail it and it was plug-and-plug on the net AND the VPN!! I thought I was pretty good at this and this damn connection has humbled me. OK, well something is probably unique to this site. Maybe it's XP. Maybe it's some registry cruft on a particular XP box. Who knows... It sounds like your VPN is alive and kicking, so pull out tcpdump on both ends and watch the traffic fly by. Maybe the problem is some wierd Microsoft DNS thing, but that doesn't really explain why small packets work but big ones don't. I strongly suspect something related to packet size and/or TCP options is causing your problems. There are actually lots of controls to diddle on this in the 'doze registry, although I try to stay as far away from this as possible. As previously mentioned, however, I *DO* run with a registry hack to reduce MTU so FreeS/WAN doesn't have to fragment my packets to get them through the VPN tunnel. In my case, this is not required, but does enhance performance. It wouldn't suprise me at all to find you have multiple XP machines that work OK, but one that doesn't based on installed patches, software, registry-hacks, network multi-player game, or whatever. Your problem seems wierd from several perspectives. While I'm sure no one has repealed the laws of physics in your corner of the world, I think we're all grasping at straws until we get some raw packet data to look at, especially since you seem to have tried all the standard quick fixes (except reducing the MTU on your internal systems, IIRC). Once we get an idea of what's going on, the place to look for the culprit (and solution) will hopefully become more apparent. DON'T GIVE UP!!! :) -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
A couple more detailsOn the local end I've used 3 different machines (my XP laptop that works over the VPN from any of the other locations, local XP laptop that belongs to one of the folks at the local site, local end W2K server) so I don't *think* it's a local machine issue. The totally uneducated vision I've had is something between the LEAF box using PPPoE to the bridged DSL router works, but somewhere the extra layer of tunnelling ipsec through PPPoE is dropping fragmented packets. Thanks, Todd OK, well something is probably unique to this site. Maybe it's XP. Maybe it's some registry cruft on a particular XP box. Who knows... It sounds like your VPN is alive and kicking, so pull out tcpdump on both ends and watch the traffic fly by. Maybe the problem is some wierd Microsoft DNS thing, but that doesn't really explain why small packets work but big ones don't. I strongly suspect something related to packet size and/or TCP options is causing your problems. There are actually lots of controls to diddle on this in the 'doze registry, although I try to stay as far away from this as possible. As previously mentioned, however, I *DO* run with a registry hack to reduce MTU so FreeS/WAN doesn't have to fragment my packets to get them through the VPN tunnel. In my case, this is not required, but does enhance performance. It wouldn't suprise me at all to find you have multiple XP machines that work OK, but one that doesn't based on installed patches, software, registry-hacks, network multi-player game, or whatever. Your problem seems wierd from several perspectives. While I'm sure no one has repealed the laws of physics in your corner of the world, I think we're all grasping at straws until we get some raw packet data to look at, especially since you seem to have tried all the standard quick fixes (except reducing the MTU on your internal systems, IIRC). Once we get an idea of what's going on, the place to look for the culprit (and solution) will hopefully become more apparent. DON'T GIVE UP!!! :) -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
Todd Pearsall wrote: Below are tcpdumps from the eth1 and then the ipsec0 interfaces. Any help in making some sense would be great. Let me know if other options, test, etc. would be more useful. If it gets too wrapped in e-mail I can make it available on the web. It's not too hard to piece back together. User on the local end makes a FTP connection remote server These dumps include the user performing an 'ls' on a small directory and then a 'get' for a file. The get hangs and eventually times out. # tcpdump -n -i eth1 net 172.30.85.0 mask 255.255.255.0 tcpdump: listening on eth1 15:13:02.074186 192.168.5.13.4426 172.30.85.100.21: P 2956246103:2956246129(26) ack 3802495246 win 63620 (DF) Your problem is immediately apparent. The (DF) in *EVERY ONE* of the packets below means Don't Fragment, which prevents the router from breaking appart your oversized packets and sending them in multiple pieces. Combined with the MSS of 1460 (which I think is larger than the data size left after PPPoE and IPSec overhead) and broken ICMP delivery, and you wind up with the results you've been seeing. The question now is *WHY* is the local client requesting Don't Fragment on all traffic, why it doesn't get handled automatically by the network stacks, and what can be done to fix it. NOTE: The don't fragment option could be getting set as part of Path MTU discovery, which is a good thing. For this to work properly, however, the ICMP error messages about a packet with don't fragment set getting dropped need to make it back to the sending host. At this point, you need to: - Figure out why the don't fragment bit is getting set. - Figure out why ICMP error messages are not being returned to the sender, or why the sender is ignoring them (note the ICMP error would be generated by a system somewhere between the remote end and your local firewall, and should be headed back to the remote FTP server). - Run a trace on both ends of the connection simultaniously, so we can see what's going on. Looks like most of the fun stuff is happening on the server side... Start with tracing the data on both ends, so we can digest it while you're looking into the other issues. At this point, if I had to hazzard a guess, I suspect the ftp return traffic (which will be a large packet) is sent by your remote FTP system, encrypted into a 1500 byte (or there abouts) packet at your firewall and thrown out to the internet. It then makes its way to your PPPoE system, where it can't be squeezed down the PPPoE link w/o fragmenting. At this point, an ICMP error message should be generated by your ISP's router (which has to drop the packet, since the DF flag is set), but they are probably blocking all ICMP traffic at their boarder, so the ICMP error packet never makes it back to the FTP server, causing Path MTU discovery to break, and your connection hangs as a result. *WARNING* The above is still just a guess...we really need to see the server-side traffic dump. You might also try setting the MSS on shorewall to whatever a 1500 byte packet minus the PPPoP and IPSec wrappers comes out to (should be online somewhere). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
I had never considered the remote end. Just for grins I put overridemtu=1200 on the remote end ipsec.conf and low and behold data transfers!!! I suspect I have patched the problem, but not addressed it. Does this change any of the steps I should be doing to continue troubleshooting or should I just tweak the remote overridemtu=1200 until I find the max that works? Thank you Charles for a huge chunk of your time!!! - Todd -Original Message- From: Charles Steinkuehler [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 4:14 PM To: Todd Pearsall Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] PPPoE, IPSec and MTU size problems Todd Pearsall wrote: Below are tcpdumps from the eth1 and then the ipsec0 interfaces. Any help in making some sense would be great. Let me know if other options, test, etc. would be more useful. If it gets too wrapped in e-mail I can make it available on the web. It's not too hard to piece back together. User on the local end makes a FTP connection remote server These dumps include the user performing an 'ls' on a small directory and then a 'get' for a file. The get hangs and eventually times out. # tcpdump -n -i eth1 net 172.30.85.0 mask 255.255.255.0 tcpdump: listening on eth1 15:13:02.074186 192.168.5.13.4426 172.30.85.100.21: P 2956246103:2956246129(26) ack 3802495246 win 63620 (DF) Your problem is immediately apparent. The (DF) in *EVERY ONE* of the packets below means Don't Fragment, which prevents the router from breaking appart your oversized packets and sending them in multiple pieces. Combined with the MSS of 1460 (which I think is larger than the data size left after PPPoE and IPSec overhead) and broken ICMP delivery, and you wind up with the results you've been seeing. The question now is *WHY* is the local client requesting Don't Fragment on all traffic, why it doesn't get handled automatically by the network stacks, and what can be done to fix it. NOTE: The don't fragment option could be getting set as part of Path MTU discovery, which is a good thing. For this to work properly, however, the ICMP error messages about a packet with don't fragment set getting dropped need to make it back to the sending host. At this point, you need to: - Figure out why the don't fragment bit is getting set. - Figure out why ICMP error messages are not being returned to the sender, or why the sender is ignoring them (note the ICMP error would be generated by a system somewhere between the remote end and your local firewall, and should be headed back to the remote FTP server). - Run a trace on both ends of the connection simultaniously, so we can see what's going on. Looks like most of the fun stuff is happening on the server side... Start with tracing the data on both ends, so we can digest it while you're looking into the other issues. At this point, if I had to hazzard a guess, I suspect the ftp return traffic (which will be a large packet) is sent by your remote FTP system, encrypted into a 1500 byte (or there abouts) packet at your firewall and thrown out to the internet. It then makes its way to your PPPoE system, where it can't be squeezed down the PPPoE link w/o fragmenting. At this point, an ICMP error message should be generated by your ISP's router (which has to drop the packet, since the DF flag is set), but they are probably blocking all ICMP traffic at their boarder, so the ICMP error packet never makes it back to the FTP server, causing Path MTU discovery to break, and your connection hangs as a result. *WARNING* The above is still just a guess...we really need to see the server-side traffic dump. You might also try setting the MSS on shorewall to whatever a 1500 byte packet minus the PPPoP and IPSec wrappers comes out to (should be online somewhere). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
Todd Pearsall wrote: I had never considered the remote end. Just for grins I put overridemtu=1200 on the remote end ipsec.conf and low and behold data transfers!!! I suspect I have patched the problem, but not addressed it. Does this change any of the steps I should be doing to continue troubleshooting or should I just tweak the remote overridemtu=1200 until I find the max that works? While additional testing is required to figure out exactly what's going on, as mentioned before I suspect the problem is when return packets hit the PPPoE link with the don't fragment bit set. In all probability, the resulting ICMP errors don't make it out of your ISP's network, although they could be hitting the firewall on your FTP server end and getting blocked (I don't know how Shorewall handles ICMP traffic by default). Regardless, with the smaller MTU forced on the remote end, your FTP server *IS* seeing the ICMP errors generated by your firewall, so Path MTU discovery works, and the FTP server correctly scales back it's transmit size (hypothetical at this point...still to be verified by packet sniffing). Using overridemtu may not be the best solution, but I think it should work properly. While it doesn't look like it's possible to set overridemtu on a per-connection basis, clamping *ALL* VPN traffic to an MTU that fits through the PPPoE links wouldn't be too bad. If you can get IPTables MSS clamping to work equally well, you should be able to clamp the MTU on only those packets traveling to the troublesome PPPoE endpoint. Thank you Charles for a huge chunk of your time!!! Glad to help. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] PPPoE, IPSec and MTU size problems
Charles Steinkuehler wrote Using overridemtu may not be the best solution, but I think it should work properly. While it doesn't look like it's possible to set overridemtu on a per-connection basis, clamping *ALL* VPN traffic to an MTU that fits through the PPPoE links wouldn't be too bad. If you can get IPTables MSS clamping to work equally well, you should be able to clamp the MTU on only those packets traveling to the troublesome PPPoE endpoint. For the archives: In the end I was able to get rid of the ipsec.conf overridemtu option on the remote end and instead set the remote ends CLAMPMSS=Yes in shorewall.conf and traffic successful passes. I *think* this a better way to do it since all vpn packets won't be forced to that size. Thanks again Charles for pushing me to see it through, it turned into quite an educational experience. I would have never thought that the solution would be modifcations on the remote end since that end is happily using 4 vpn connections for ages now. I also just realized why the old rsa keys I as using would establish a connection, but the new ones I'm moving all vpns do wouldn't. The old keys were 1024bit, the new ones are 2048bit, so they are still getting dropped somewhere along the way. But I now have time to work that out since everything is up and running. Thanks again. - Todd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
RE: [leaf-user] It Works!!
There's obviously Pitts' everywhere!! I'm using the three interface Shorewall config (which, once I'd figured out how to set rules, works beautifully and easily), no ipsec. Eth1 is on 192.168.1.0, eth2 on 192.168.2.0. David Pitts IT Services Manager Reid Library University of Western Australia Telephone: (08) 9380 3492 Fax: (08) 9380 1012 -Original Message- From: Lynn Avants [mailto:[EMAIL PROTECTED]] Sent: Thursday, 13 February 2003 11:45 PM To: [EMAIL PROTECTED] Subject: Re: [leaf-user] It Works!! On Wednesday 12 February 2003 07:24 pm, David Pitts wrote: Lynn, maybe you mean me, not 'Dan'?? Anyway, I was/am using a Bering stable 1.0 with ezipupdt.lrp and BPALogin.lrp. I deleted some packages I didn't need like bridge.lrp, keyboard.lrp, ppp.lrp and pppoe.lrp. I also had pump and dhcpd out when I was playing with uDHCP. Sorry about the wrong name there David brainfart, I have a co-worker named Dan Pitts and I guess I get confused sometimes. ;-) Thanks for the information, further you have added ipsec correct? Have you changed the internal subnet from 1922.168.1.0? -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] PPPoE, IPSec and MTU size problems
Todd Pearsall wrote: Charles Steinkuehler wrote Using overridemtu may not be the best solution, but I think it should work properly. While it doesn't look like it's possible to set overridemtu on a per-connection basis, clamping *ALL* VPN traffic to an MTU that fits through the PPPoE links wouldn't be too bad. If you can get IPTables MSS clamping to work equally well, you should be able to clamp the MTU on only those packets traveling to the troublesome PPPoE endpoint. For the archives: In the end I was able to get rid of the ipsec.conf overridemtu option on the remote end and instead set the remote ends CLAMPMSS=Yes in shorewall.conf and traffic successful passes. I *think* this a better way to do it since all vpn packets won't be forced to that size. Thanks again Charles for pushing me to see it through, it turned into quite an educational experience. I would have never thought that the solution would be modifcations on the remote end since that end is happily using 4 vpn connections for ages now. I also just realized why the old rsa keys I as using would establish a connection, but the new ones I'm moving all vpns do wouldn't. The old keys were 1024bit, the new ones are 2048bit, so they are still getting dropped somewhere along the way. But I now have time to work that out since everything is up and running. WARNING: While I don't run IPTables, my understanding of how the CLAMPMSS setting in IPTables (and thereby shorewall) works is by modifying the MSS field in TCP headers as they traverse the router. This works fine for a connection based protocol like TCP, but will do nothing for stateless protocols like UDP (or AH/ESP used by IPSec). If you are having Path MTU discovery problems, I think using *ONLY* the clampmss will probably get most things working, but leave strange, nearly unexplainable problems cropping up periodically. Thinking about this, I think the only way to reliably fix the problem is to use the overridemtu setting in FreeS/WAN (so path mtu discovery works properly from the internal network's perspective), or to manually force the maximum MTU to a value smaller than 1500 on all affected internal systems (an administrative nightmare)...of course, an exact determination of why path mtu discovery is failing might reveal an alternate solution, but if the problem is being caused by your ISP on one (or both) end(s) of the link, it may not be fixable by you (I can just imagine calling up your ISP's tech support, asking them to change their router settings because they're breaking Path MTU discovery and violating RFC's). At least it's working now, and you can start tweaking. Oh...and I believe you would have had this problem with the commercial router as well, although it would have been a good test for their tech support staff... -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en 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
Re: [leaf-user] Cisco VPN client through (Dachstein) LRP
On Thursday 13 February 2003 09:46 pm, [EMAIL PROTECTED] wrote:
Lynn,
I found your ipsec.txt, thanks.
One questioncould you give me an example of how to use ipfwd to
forward the port to my internal network. My LRP box is at 192.168.1.1
with gateway at 192.168.1.254 and I am using dhcpd.
Open the port (500):
EXTERN_UDP_PORTS=0/0_domain 0/0_bootpc 0/0_500
Open the protocols (50 51):
EXTERN_PORTS=50_0.0.0.0 51_0.0.0.0
Forward the service to the LAN machine (WAN is DHCP):
INTERN_SERVERS=udp_${EXTERN_IP}_500_192.168.1.1_500
firewall-# svi network reload
I hope this helps!
--
~Lynn Avants
Linux Embedded Appliance Firewall developer
http://leaf.sourceforge.net
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
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
[leaf-user] LEAF at OSCON
Are any LEAF participants attending OSCON this year? If so, are any of you putting a
proposal to do a presentation on LEAF?
If the answer to the second question is no, I will be submitting a proposal for either
a 45min or 90min presentation by tomorow afternoon.
I have not been that involved with the project in the past few months, but enjoy
giving presentations and can coordinate with team members to put together good
coverage of topics.
I wish to give a basic overview of what LEAF is, how one might use it, an intro to
some of the active distributions, and possible some view of the new
config/web-management pieces we are working on.
Richard Amerman
áÄ
4DÞ¨¥Ë)¢{(ç[ÈTD$èyúè8ZÂ×쨺Zx§*.gIêïz´rêâ·
¥É!z·¢hTD8ZÂ×H¸.××âÛay©ìÁê춥*.$±ç.®+rË.zÈm¶ÿiÛ,¢êÜyú+éÞ·÷
¸§þ··¶m
¬4ÓnW~ë ®f¢)à+-æºÇ«+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþW~ë $Em¶ÿ榺#yËh®é¹¿Ý¡Ïݡɨ ¯÷hr'uóÝa¶i
