[leaf-user] [ leaf-Support Requests-594097 ] Dachstein will not start on 486/100.....
Support Requests item #594097, was opened at 2002-08-13 03:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=594097group_id=13751 Category: Release/Branch: Dachstein Group: None Status: Open Priority: 5 Submitted By: Dion Bird (dionb98) Assigned to: Mike Noyes (mhnoyes) Summary: Dachstein will not start on 486/100. Initial Comment: Dachstein will not start on my 486 DX4/100 with 32MB of RAM. Here is a summary of the boot process before it locks up. IP Filters: [IP Forwarding: DISABLED] flushed SIOCGIFFLAGS: Operation not supported by device Bind socket to interface: Operation not supported by device exiting Starting Network: [IP Always Defrag: ENABLED] IP filters: firewall [IP Forwarding: ENABLED] Loopback interface: lo Starting interface: Cannot find device eth1 SIOCGIFFLAGS: Operation not supported by device eth1 Hostname: firewall Static NS: 2 hosts At this point the cursor just sits and flashes. On my other systems the disk will boot completely, with the summary I have provided, same as what's written above. (Including the operation not supported by device stuff) Any insight on why it won't continue past this point on the 486? As I said before it is a 486 DX4/100 with 32MB RAM. I have stripped it down to just the PCI video card and the PCI NIC card. I've tried booting it with no NIC card, and 1 card and 2 cards. If I boot the system under Windows 98, it will detect the network cards so they appear to be functioning. I would appreciate any suggestions you have. Dion -- Comment By: magic freeman (kiwispaniol) Date: 2002-11-16 23:21 Message: Logged In: YES user_id=650015 hi Dion sorry for asking about other stuff does this Dachstein supports dial on demand (56k modem) today is the first time i read about it, i cant find more info about it. cheers mate freeman -- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-15 02:30 Message: Logged In: NO Have you configured the NIC's with DOS?, What is the make and model of your NIC's Are you loading the right drivers? example: NE2000-pci = pciscan + 8390 + ne2k-pci modules to load. Is your BIOS set to PNP os? Peter -- Comment By: Lynn Avants (guitarlynn) Date: 2002-08-14 15:41 Message: Logged In: YES user_id=176069 Some old BIOS's do not detect the larger floppy format that the LEAF distro's use. A BIOS update may or may not allow for the larger format and I do not know of a definate fix that works for this problem. You may need to reduce your LEAF disk to fit on a 1.44M formatted disk or use a different machine. Unfortunately this is the best advice I can give on this one. I hope it helps, ~Lynn -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=213751aid=594097group_id=13751 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] Leaf LINCE
Hi, Great! The WP'ed SST dom would also be a great option (or CD-ROM). I'll love to check it out! Yes, could you give me the link for that DOM? Out of curiousity, do you really feel the http/smtp/pop proxy should be on the firewall? I understand many people would love this option, but to many people (especially for enterprise installations) this would seem to be akin to sending invitations to hackers by filtering on the firewall. Yes indeed. We put all those components in the Compact Flash or Hard Disk, then is your choice what you want / need to activate but all will be ready to go. In a small company you might end up activating all of them, in an enterprise level compamy you might end up not activating any extra because you already have them in other / better hardware. Say the http load balancer. If you need such a feature you surelly wont activate anithing but that getting a cheap HTTP Alteon equivalent, but if you are a big company with lots of bucks you would already have an Alteon or Cisco or whatever. I dont think Linux (Leaf) can compete with such hardwarem but htey lack the flexibility. So we give you the swish army knife firewall :) You have plenty of features on it, and you decide wich ones to use. I'm sure many of us would contribute when and if we have the time! I know, its just we had a very sad experience with our LUG. Leaf is already a quite active development community. Things we are planning to add in the near feature: 1) Bridge functionality. Yes, this is done with Bering but we have never done it, need to learn how to do it. 2) Proxy ARP - the same There are many of us using both of these options. The proxy-arp is easy to test if you don't mind opening the server to the internet less securely IMHO. The bridge option simply uses the box as a hub. It can be used to tie together tp-10/100, bnc, fiber, etc..., however tp-to-tp testing would be adaquate. 3) HTTP load balancer.- We are just awaiting somebody will pay us to do this :) 4) SNORT, inline SNORT, high availability (heartbeat), David D/Oxygen has a snort package available, though I have not used it personally. We have a volunteer that is working in this side. We might end up with a snort sensor or in other option with hogwash to make a inline IDS capable of dropping packages based on IDS signatures (only way to protect an exploitable server). Many of us are doing this, in various degree's. Best of luck to succeeding in your project, I hope to someday do the same successfully! Yes I know, is the beaty of OS. We all try to compete in the same business but at the same time need to colaborate :) Here in Spain Barahona, one of the OS evangelists gies a little talk just of that and is really incredible. Also, is quite easier to get real knowledge because you end up knowing how the guts of it go. Regards -- Jaime Nebrera Herrera [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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: Bering Download Problems (was Re: [leaf-user] Bering v1.0-stable released !)
Le Samedi 16 Novembre 2002 01:28, Jeff Newmiller a écrit : On Sat, 16 Nov 2002, hari-nuryadi wrote: Wonderful works Jaques :) , keep on it and congratulation for the good stable LEAF OS. Btw, i always get this messages when i'm trying to d/l the stable release: Could not read file. Go back. Nov 15, 2002 15:28 What's happen? b) I followed his link and downloaded from Pheonix, AZ (http://prdownloads.sourceforge.net/leaf/Bering_1.0-stable_img_bering_1680. bin?use_mirror=easynews) and succeeded. I seems to me that some mirrors are lagging behind in term of sync. Right now only 4 mirrors appear to be OK: Brookfield, WI OK (twtelecom) OK Chapel Hill, NC (unc) Not in sync Minneapolis, MN (umn) Not in sync Phoenix, AZ (easynews) OK Reston, VA (telia) Not in sync Zurich, Switzerland (switch) OK Prague, Czech Republic (cesnet) OK Brussels, Belgium (belnet) Not in sync c) I have actually encountered a similar error when I reviewed his documentation file http://leaf.sourceforge.net/devel/jnilo/bidownmod.html and attempted to download the modules file using the here link at the bottom of the page. Apparently a space is inserted between the tar. and the gz that prevents the link from working as-is, though you can copy the link, edit it, and paste that into your browser as a workaround. My bad. Error corrected thanks. Jacques --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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:Re:[leaf-user] ipsec Bering
As you ask me, i put below the output of ipsec barf and the output of auth.log : The ipsec barf command was launch after i try to initiate the tunnel from my road-warrior (using a RAS connection to an ISP). The problem seems to come from the 3 lines from auth.log : Nov 16 13:39:21 firewall pluto[24215]: w2k-road-warriors[2] 62.147.113.146 #4: route-client output: RTNETLINK answers: Network is unreachable Nov 16 13:39:21 firewall pluto[24215]: w2k-road-warriors[2] 62.147.113.146 #4: route-client output: /lib/ipsec/_updown: `ip route add 62.147.113.146/32 dev ipsec0 via 62.147.113.146' failed Nov 16 13:39:21 firewall pluto[24215]: w2k-road-warriors[2] 62.147.113.146 #4: route-client command exited with status 2 Thanks in advance. Stephane IPSEC BARF output : firewall Sat Nov 16 13:40:35 UTC 2002 + _ version + + ipsec --version Linux FreeS/WAN 1.98b See `ipsec --copyright' for copyright information. + _ proc/version + + cat /proc/version Linux version 2.4.18 (root@samsung) (gcc version 2.95.4 20011002 (Debian prerelease)) #6 Sun Oct 20 15:06:22 CEST 2002 + _ proc/net/ipsec_eroute + + sort +3 /proc/net/ipsec_eroute sort: +3: No such file or directory + cat /proc/net/ipsec_eroute + _ ip/route + + ip route ip.pub.lik.1 dev ppp0 proto kernel scope link src ip.pub.lik.254 ip.pub.lik.1 dev ipsec0 proto kernel scope link src ip.pub.lik.254 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.230 default via ip.pub.lik.1 dev ppp0 + _ proc/net/ipsec_spi + + cat /proc/net/ipsec_spi + _ proc/net/ipsec_spigrp + + cat /proc/net/ipsec_spigrp + _ proc/net/ipsec_tncfg + + cat /proc/net/ipsec_tncfg ipsec0 - ppp0 mtu=16260(1492) - 1492 ipsec1 - NULL mtu=0(0) - 0 ipsec2 - NULL mtu=0(0) - 0 ipsec3 - NULL mtu=0(0) - 0 + _ proc/net/pf_key + + cat /proc/net/pf_key sock pid socket next prev e n p sndbfFlags Type St c159c400 24215 c118c1b000 0 0 2 65535 3 1 + _ proc/net/pf_key-star + + cd /proc/net + egrep ^ pf_key_registered pf_key_supported pf_key_registered:satype socket pid sk pf_key_registered: 2 c118c1b0 24215 c159c400 pf_key_registered: 3 c118c1b0 24215 c159c400 pf_key_registered: 9 c118c1b0 24215 c159c400 pf_key_registered:10 c118c1b0 24215 c159c400 pf_key_supported:satype exttype alg_id ivlen minbits maxbits pf_key_supported: 2 14 3 0 160 160 pf_key_supported: 2 14 2 0 128 128 pf_key_supported: 3 15 3 128 168 168 pf_key_supported: 3 14 3 0 160 160 pf_key_supported: 3 14 2 0 128 128 pf_key_supported: 9 15 4 0 128 128 pf_key_supported: 9 15 3 0 32 128 pf_key_supported: 9 15 2 0 128 32 pf_key_supported: 9 15 1 0 32 32 pf_key_supported:10 15 2 0 1 1 + _ proc/sys/net/ipsec-star + + cd /proc/sys/net/ipsec + egrep ^ icmp inbound_policy_check tos icmp:1 inbound_policy_check:1 tos:1 + _ ipsec/status + + ipsec auto --status 000 interface ipsec0/ppp0 ip.pub.lik.254 000 000 w2k-road-warriors[2]: 192.168.0.0/24===ip.pub.lik.254...62.147.113.146 000 w2k-road-warriors[2]: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 w2k-road-warriors[2]: policy: PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; unrouted 000 w2k-road-warriors[2]: newest ISAKMP SA: #3; newest IPsec SA: #0; eroute owner: #0 000 w2k-road-warriors[1]: 192.168.0.0/24===ip.pub.lik.254...62.147.151.223 000 w2k-road-warriors[1]: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 w2k-road-warriors[1]: policy: PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; unrouted 000 w2k-road-warriors[1]: newest ISAKMP SA: #1; newest IPsec SA: #0; eroute owner: #0 000 w2k-road-warriors: 192.168.0.0/24===ip.pub.lik.254...%any 000 w2k-road-warriors: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 w2k-road-warriors: policy: PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ppp0; unrouted 000 w2k-road-warriors: newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0 000 sample: 172.16.0.0/24===10.0.0.1---10.22.33.44...10.101.102.103---10.12.12.1===192.168.0.0/24 000 sample: ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 sample: policy: PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: ; unrouted 000 sample: newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0 000 000 #3: w2k-road-warriors[2] 62.147.113.146 STATE_MAIN_R3
[leaf-user] Problem with pppoe
I tell a friend about LEAF so he tries to setup the bering 1.0 rc3 ( the same version that i have) We connect both with adsl and the same provider. My connection works well but my friend got this message (from syslog) Plugin /usr/lib/pppd/pppoe.so loaded PPPoE Plugin Initialized pppd started by root, uid 0 Sending PADI the plugin is initialized but (from syslog): Nov 15 23:17:45 firewall pppd[7330]: invalid packet Ether addr: 14:22:f0:bf:6c:8f PPPoE hdr: ver=0xf type=0x9 code=0x11 sid=0x002b length=0x5422 (Unknown) PPPoE tag: type=f0bf length=6c8f (Unknown) unrecognized data Nov 15 23:17:45 firewall pppd[7330]: Failed to negotiate PPPoE connection: 4 Interrupted system call Nov 15 23:17:45 firewall pppd[7330]: Exit. The config file are ok, he has the same as me. He has two 3com 3c509b NIC's. I read it from mail-archive, but I don't think my friend is in the case described by Charles Steinkuehler : I've tried the above with and without quotes. Either combination yields the following from syslog: Plugin /usr/lib/pppd/pppoe.so loaded PPPoE Plugin Initialized pppd started by root, uid 0 Sending PADI And then just sits there... Depending on when I ifdown ppp0, syslog reports the following: invalid packet Ether addr:14:89:fa:bf:6c:6f PPPoE hdr: ver=0xf type=0x9 code=0xf1 sid=0x4aeb length=0x5489 (UNKNOWN) PPPoE tag: type=fabf length=6c6f (UNKNOWN) unrecognized data Failed to negotiate PPPoW connection: 4 Interrupted system call If I don't ifdown ppp0, it just sits at Sending PADI indefinitely. Any thoughts? I'd say the odds are on something mis-configured in your PPP or PPPoE setup. I had virtually no luck with PPPoE until I setup a test PPPoE network, and could look at the logs on *BOTH* sides of the connection. Once I got the kinks out of my test configuration, linking up with an actual provider went smoothly. It may help to connect a full-blown disto to your PPPoE link (or bum some config files off someone on-list with a linux box hooked to SWBT PPPoE DSL), and compare the configuation with what you're setting up in LEAF. One thing working with a thin disto like LEAF is you're forced to learn how to make everything run at a very low-level. This can be a good thing or a bad thing, depending on your perspective. I learned *WAY* more about software RAID by building a LEAF based web-server sporting a SCSI RAID-1 than by installing RedHat and using the GUI installer to build mirrored partitions...in fact, I learned enough playing with RAID on LEAF that I now trust it for production servers, and know I can fix things if I ever loose a drive. Charles Steinkuehler I really need help, so if someone have an idea Thanks Sylvain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] Simple autofw problem
I attached the tcpdump snippet so you can see that there are indeed packets hitting the external interface, with a source port of 6000-6999/udp, and (what I assume to be) an ephemeral destination port, which in this case happens to be in the 61XXX/udp range. The service being forwarded is the voice chat function in the Playstation2 game SOCOM Navy Seals. As I said in the first message, this service works when I bypass the firewall. Its only when I have the PS2 behind the firewall that I have problems *receiving* voice from other players. At all times, my voice can be sent to other players (since the firewall does not block any *outbound* services). I have the autofw module loaded, as well as the following: # lsmod Module PagesUsed by ip_masq_portfw 2296 2 ip_masq_autofw 2356 0 ip_masq_user2636 0 (unused) ip_masq_raudio 2820 0 (unused) ip_masq_ftp 2352 0 (unused) wd 4404 1 ne 6276 1 83906220 0 [wd ne] You said I am blocking udp 4...is this a special udp message type or what? How would I go about opening it and forwarding this type of packet? Hope this sheds some more light on what I am trying to accomplish, and why it isn't working. All help is appreciated. Billy From: guitarlynn [EMAIL PROTECTED] To: billy jacobs [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [leaf-user] Simple autofw problem Date: Sat, 16 Nov 2002 01:06:49 -0600 On Friday 15 November 2002 19:53, billy jacobs wrote: Comments inline ;-) EXTERN_UDP_PORTS=0/0_domain 0/0_6000:6999 INTERN_PS2_SERVER=192.168.1.9 OK, you've opened the 6000-6999 udp port range. Relevant parts of /etc/ipfilter.conf (added right after other forwarding 'if' statements): ~ if [ -n $INTERN_PS2_SERVER ] ; then $IPCH -A input -s 0.0.0.0/0 -d $INTERN_PS2_SERVER 6000:6999 -p udp -j ACCEPT $IPMASQADM autofw -A -v -r udp 6000 6999 -h $INTERN_PS2_SERVER fi OK, the port range is forwarded to 192.168.1.9 address. Output of ipchains -L -n |grep 6000 ~ # ipchains -L -n |grep 6000 ACCEPT udp -- 0.0.0.0/0192.168.1.9 * - 6000:6999 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 * - 6000:6999 The changes appear to be active. Output of tcpdump -i eth0 | grep \.6... (to filter on range): ~ 20:26:14.406460 pcp01120514pcs.flshng01.mi.comcast.net.6565 66-108-7-175.nyc.rr.com.61717: udp 4 20:26:17.446460 dy251162.resnet.uky.edu.6091 66-108-7-175.nyc.rr.com.61487: udp 4 20:26:19.406460 pcp01120514pcs.flshng01.mi.comcast.net.6565 66-108-7-175.nyc.rr.com.61717: udp 4 20:26:24.396460 pcp01120514pcs.flshng01.mi.comcast.net.6565 66-108-7-175.nyc.rr.com.61717: udp 4 20:26:27.446460 dy251162.resnet.uky.edu.6091 66-108-7-175.nyc.rr.com.61487: udp 4 Ok, your blocking udp 4. This port is not opened much less forwarded. I'm not sure how this applies to your added configuration. Any ideas? Help would be appreciated. It would help if we had any idea what you are attempting to forward service wise. I'm not clear on what you are attempting to show with the tcpdump. Have you loaded the autofw module? More information is requested so we can atleast make a guess at what the problem may be. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] thttpd behind lrp
C. Dummy wrote: I'm trying to put thttpd behind lrp box on ip 192.168.1.203. I made lrp floppy with etc,ifconfig,local,modules,ramlog,root,thttpd and www-data packages. I edited syslinux.cfg so all packages load no errors and problems. I edited network.conf CONFIG_DNS=YES IF_AUTO=eth0 eth0_IPADDR=192.168.1.203 eth0_MASKLEN=24 eth0_DEFAULT_GW=192.168.1.254 eth1_IPADDR= eth1_MASKLEN= IPFILTER_SWITCH=none EXTERN_DHCP=NO INTERN_WWW_SERVER=192.168.1.203# Internal WWW server to make available When I boot the floppy I don't get any errors and I can ping machines on LAN no problem. Thttpd and www-data are original files from packages(no changes made) I can't see anything from LAN using http://192.168.1.203(connecting... and nothing no message it just dies) or http://ip.binded.to.lrp.box(the connection was refused when attempting to contact ip.binded.to.lrp.box) can't see anything from outside either(the page cannot be displayed). Where is the problem? Thanks for help. I'm complete newbie with setting up web server sorry if this sounds silly. Andrey P.S.Ifconfig inet addr:192.168.1.203 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCASTRUNNING MULTICAST MTU:1500 Metric:1 Turn off the port-forwarding, which makes no sense in your situation. To do this, comment out the last line above, ie: # INTERN_WWW_SERVER=192.168.1.203 Other than that, if you need any more help, you should provide the output of the following commands, so we know more about your system setup: ip addr ip route net ipfilter liet netstat -ln -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] LaBrea
C. Dummy wrote: Hi I'm running Dachstein 1.02 with pppoe and with printer server(protocol RAW port 9100).. I have installed LaBrea. I edited both files in /etc listing my used network adresses. When I boot lrp box I get message: P-lookupnet(eth0): SIOCGIFADDR:eth0:cannot assign requested address I tried to look in geocrawler but there is not to much about LaBrea there? Anybody has any idea how to fix that? Andrey Thanks for help It's hard to say what's going on here. Exactly when does the above error occur? You mention it's at boot time, but a lot of stuff is happening. Without any context, it's hard to guess what might be causing this error. Running the printer server and LaBrea are both very non-standard configurations, and PPPoE could be causing problems as well. With the lack of any detailed configuration information, about the only thing I can suggest for trying to fix things is see if you can isolate the problem to a particular Package (perhaps LaBrea or your print server), then see if you can figure out what in the init scripts is breaking. WARNING: As I have said many times before, LaBrea can be a *VERY* nasty program when used improperly, and has the potential to completely disrupt otherwise normal networks (meaning you can easily break not only your upstream network connection, but potentially the connections of lots of your neighbors, as well...in some cases, human intervention by your ISP's IT staff may even be required to get things back to normal). You should not be using LaBrea unless you completely understand how it works, and understand how it will interact with both your network and the network of your upstream provider. There should be several good e-mails on configuring LaBrea in the list archives, if you still want to take the plunge... -- Charles Steinkuehler [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] Simple autofw problem
Please explain a bit more carefully what you are trying to accomplish. There are two items of significance in what you've told us that require clarification. (And it appears that your calling this problem simple in the Subject line is a bad call ... but read on.) First, you say you are forwarding ports 6000-6999 to an internal host. That's fine. But the tcpdump traffic you report seeing involves (according to your report) *source* ports in that range. Forwarding applies to *destination* ports. Does tcpdump find any packets going *to* 6000-6999 on eth0? Second, you say the traffic goes to (what I assume to be) an ephemeral destination port, which in this case happens to be in the 61XXX/udp range. This range is more than happenstance; it is in the range that the router uses for NAT'd connections. So, what *appears* to be happening is that the router is NAT'ing outgoing connections from the Playstation 2, and remote systems are attempting to reply to the NAT'd ports. Why these attempted replies do not reach the Playstation is not apparent from what you have told us; the earlier suggestion that you need to use tcpdump to look at LAN-side traffic is probably still the right next step. Nor is it apparent why they do not send traffic to destination ports in the 6000-6999 range (or even for sure that they do not, since that traffic might appear elsewhere in your tcpdump outout). Not being more than casually familiar with the Playstation 2 myself, I can't suggest a fix ... that will require help from someone with more intimate knowledge of the service you are trying to forward. I suspect you're actually plowing new ground, at least with respect to LEAF, and making this service work through a LEAF router will require some research on your (or someone's) part. It may also require that you move from Dachstein to a LEAF variant, like Bering, that uses the 2.4.x kernel and iptables, which offers more flexibility in setting up specialized NATing rules. Looking at your tcpdump output, Lynn's earlier reference to UDP port 4 was simply a slip of the tongue (or, more apt, the fingers). The 4 in your listings is the packet length, not the source or destination port. BTW, in all of the above, I've assumed that you are 66-108-7-175.nyc.rr.com, NOT pcp01120514pcs.flshng01.mi.comcast.net . You never actually tell us, and your use of a hotmail e-mail address doesn't help me to guess. If I am wrong in this assumption, I've done the analysis backwards ... ond once again, we've seen the difficulty of trying to troubleshoot based on fragmentary reports from users. At 10:44 AM 11/16/02 -0500, billy jacobs wrote: I attached the tcpdump snippet so you can see that there are indeed packets hitting the external interface, with a source port of 6000-6999/udp, and (what I assume to be) an ephemeral destination port, which in this case happens to be in the 61XXX/udp range. The service being forwarded is the voice chat function in the Playstation2 game SOCOM Navy Seals. As I said in the first message, this service works when I bypass the firewall. Its only when I have the PS2 behind the firewall that I have problems *receiving* voice from other players. At all times, my voice can be sent to other players (since the firewall does not block any *outbound* services). I have the autofw module loaded, as well as the following: # lsmod Module PagesUsed by ip_masq_portfw 2296 2 ip_masq_autofw 2356 0 ip_masq_user2636 0 (unused) ip_masq_raudio 2820 0 (unused) ip_masq_ftp 2352 0 (unused) wd 4404 1 ne 6276 1 83906220 0 [wd ne] You said I am blocking udp 4...is this a special udp message type or what? How would I go about opening it and forwarding this type of packet? Hope this sheds some more light on what I am trying to accomplish, and why it isn't working. All help is appreciated. Billy From: guitarlynn [EMAIL PROTECTED] To: billy jacobs [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [leaf-user] Simple autofw problem Date: Sat, 16 Nov 2002 01:06:49 -0600 On Friday 15 November 2002 19:53, billy jacobs wrote: Comments inline ;-) EXTERN_UDP_PORTS=0/0_domain 0/0_6000:6999 INTERN_PS2_SERVER=192.168.1.9 OK, you've opened the 6000-6999 udp port range. Relevant parts of /etc/ipfilter.conf (added right after other forwarding 'if' statements): ~ if [ -n $INTERN_PS2_SERVER ] ; then $IPCH -A input -s 0.0.0.0/0 -d $INTERN_PS2_SERVER 6000:6999 -p udp -j ACCEPT $IPMASQADM autofw -A -v -r udp 6000 6999 -h $INTERN_PS2_SERVER fi OK, the port range is forwarded to 192.168.1.9 address. Output of ipchains -L -n |grep 6000 ~ # ipchains -L -n |grep 6000 ACCEPT udp -- 0.0.0.0/0192.168.1.9 * - 6000:6999 ACCEPT
Re: [leaf-user] Simple autofw problem
OK, what I thought would be a simple autofw problem turns out to be much more in-depth than I thought it would be. My slip up is that I assumed that I could forward based on the source port, and not the destination. You are absolutely correct -- I am plowing new ground here, because there is very limited information on exactly how this service works. From all the documentation I found on the web (almost all from end-users), they are all using linksys routers (or similar devices), and their end-all answer is to put it on the DMZ. I was trying to avoid setting up any kind of DMZ setup off my router. The only IP-specific (and not router model specific) information I have found is to simply forward 6000-6999/udp to the PS2. Of course, they never mention if thats a source port or destination port, but going by the tcpdump trace, I can only assume its a source 6000-6999/udp. Again, lack of techincal specifics on how this service works is holding me back. You were correct to assume that my address is the rr.com address. I apologize for not going much more in depth when I started out this thread, because as I said, I thought it would be much simpler (incorrect ipchains syntax, for example). I was actually a little unsure about just posting only the relevant parts of network.conf and ipfilter.conf. From reading prior posts, at least for me, its very easy to get lost in all of the extra information presented when people post complete conf files. So that is my fault for not giving at least a little more detail on my setup. I assume with iptables, the --source-port and --dport would be the keys to doing what I am trying to do. They would allow me to specify packets which match the source ports I am looking at and forward them to an internal host. IPChains/IPMasqadm don't have this functionality built in, right? It sounds like I will have to take this discussion off-line and do some research on my own. I appreciate all the help and explanations you guys have given. Billy ___ Please explain a bit more carefully what you are trying to accomplish. There are two items of significance in what you've told us that require clarification. (And it appears that your calling this problem simple in the Subject line is a bad call ... but read on.) First, you say you are forwarding ports 6000-6999 to an internal host. That's fine. But the tcpdump traffic you report seeing involves (according to your report) *source* ports in that range. Forwarding applies to *destination* ports. Does tcpdump find any packets going *to* 6000-6999 on eth0? Second, you say the traffic goes to (what I assume to be) an ephemeral destination port, which in this case happens to be in the 61XXX/udp range. This range is more than happenstance; it is in the range that the router uses for NAT'd connections. So, what *appears* to be happening is that the router is NAT'ing outgoing connections from the Playstation 2, and remote systems are attempting to reply to the NAT'd ports. Why these attempted replies do not reach the Playstation is not apparent from what you have told us; the earlier suggestion that you need to use tcpdump to look at LAN-side traffic is probably still the right next step. Nor is it apparent why they do not send traffic to destination ports in the 6000-6999 range (or even for sure that they do not, since that traffic might appear elsewhere in your tcpdump outout). Not being more than casually familiar with the Playstation 2 myself, I can't suggest a fix ... that will require help from someone with more intimate knowledge of the service you are trying to forward. I suspect you're actually plowing new ground, at least with respect to LEAF, and making this service work through a LEAF router will require some research on your (or someone's) part. It may also require that you move from Dachstein to a LEAF variant, like Bering, that uses the 2.4.x kernel and iptables, which offers more flexibility in setting up specialized NATing rules. Looking at your tcpdump output, Lynn's earlier reference to UDP port 4 was simply a slip of the tongue (or, more apt, the fingers). The 4 in your listings is the packet length, not the source or destination port. BTW, in all of the above, I've assumed that you are 66-108-7-175.nyc.rr.com, NOT pcp01120514pcs.flshng01.mi.comcast.net . You never actually tell us, and your use of a hotmail e-mail address doesn't help me to guess. If I am wrong in this assumption, I've done the analysis backwards ... ond once again, we've seen the difficulty of trying to troubleshoot based on fragmentary reports from users. At 10:44 AM 11/16/02 -0500, billy jacobs wrote: I attached the tcpdump snippet so you can see that there are indeed packets hitting the external interface, with a source port of 6000-6999/udp, and (what I assume to be) an ephemeral destination port, which in this case happens to be in the
Re: [leaf-user] LaBrea
I removed p9100 from syslinux.cfg I still get: Right at the end snip Starting additional networking services: dnscache queries allowed from 192.168 dnscache queries allowed from 127.0.0.1 Starting dnscache without daemontools ... Starting LaBrea Tarpitpcap_lookupnet(eth0): SIOCGIFADDR: eth0: Cannot assign requested address. Linux Router 4.0.6 firewall tty1 snip I think LaBrea must have problems with pppoe. I just leave box without LaBrea its not a must have package. Thanks for help Charles Steinkuehler wrote: C. Dummy wrote: Hi I'm running Dachstein 1.02 with pppoe and with printer server(protocol RAW port 9100).. I have installed LaBrea. I edited both files in /etc listing my used network adresses. When I boot lrp box I get message: P-lookupnet(eth0): SIOCGIFADDR:eth0:cannot assign requested address I tried to look in geocrawler but there is not to much about LaBrea there? Anybody has any idea how to fix that? Andrey Thanks for help It's hard to say what's going on here. Exactly when does the above error occur? You mention it's at boot time, but a lot of stuff is happening. Without any context, it's hard to guess what might be causing this error. Running the printer server and LaBrea are both very non-standard configurations, and PPPoE could be causing problems as well. With the lack of any detailed configuration information, about the only thing I can suggest for trying to fix things is see if you can isolate the problem to a particular Package (perhaps LaBrea or your print server), then see if you can figure out what in the init scripts is breaking. WARNING: As I have said many times before, LaBrea can be a *VERY* nasty program when used improperly, and has the potential to completely disrupt otherwise normal networks (meaning you can easily break not only your upstream network connection, but potentially the connections of lots of your neighbors, as well...in some cases, human intervention by your ISP's IT staff may even be required to get things back to normal). You should not be using LaBrea unless you completely understand how it works, and understand how it will interact with both your network and the network of your upstream provider. There should be several good e-mails on configuring LaBrea in the list archives, if you still want to take the plunge... --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] Simple autofw problem
At 12:33 PM 11/16/02 -0500, billy jacobs wrote: OK, what I thought would be a simple autofw problem turns out to be much more in-depth than I thought it would be. My slip up is that I assumed that I could forward based on the source port, and not the destination. You are absolutely correct -- I am plowing new ground here, because there is very limited information on exactly how this service works. From all the documentation I found on the web (almost all from end-users), they are all using linksys routers (or similar devices), and their end-all answer is to put it on the DMZ. I was trying to avoid setting up any kind of DMZ setup off my router. The only IP-specific (and not router model specific) information I have found is to simply forward 6000-6999/udp to the PS2. Of course, they never mention if thats a source port or destination port, but going by the tcpdump trace, I can only assume its a source 6000-6999/udp. Without seeing the documentation you refer to here, I'd be reluctant to guess how those others are using the term forward. But in a Linux/LEAF context, the unqualified instruction forward 6000-6999/udp would invariably refer to destination ports. Since I don't know how Linksys or similar devices handle DMZs, that info gices me no added clues. As to the tcpdump trace, I am puzzled that it shows *no* outgoing traffic either from the NAT ports (which \.6... should grep quite nicely, but \.6... would miss -- which did you really use?) or to any remote 6000-6999 ports (which either regex should match). You might want to look at less-filtered tcpdump output to get a better understanding of what is going on. Again, lack of techincal specifics on how this service works is holding me back. Welcome to Linux. Not that this is Linux's fault, but people who provide information tend to assume that Windows is the lingua franca of computing, so often do not provide answers in forms useful to Linux users or developers. Teasing out the relevant facts is a common skill among Linux developers. You were correct to assume that my address is the rr.com address. I apologize for not going much more in depth when I started out this thread, because as I said, I thought it would be much simpler (incorrect ipchains syntax, for example). I was actually a little unsure about just posting only the relevant parts of network.conf and ipfilter.conf. From reading prior posts, at least for me, its very easy to get lost in all of the extra information presented when people post complete conf files. So that is my fault for not giving at least a little more detail on my setup. This is worth a comment, because it is a misguided reason for refraining from posting the necessary details, and others may feel the way you do. Detail may confuse inexperienced users of LEAF distros, but it helps experienced users and developers. You're more likely to get help from an experienced LEAF user or developer than a beginner (simply because experienced users and developers know more), so you want to include what we need, even if seeing it from others causes you to get lost. This is especially true when the omitted detail forces us to guess about which half of a connection pair is your end, which the remote end. The SR FAQ is a good (not perfect, but good) starting guide here, and you'll notice that it asks for output of commands, NOT config files. I assume with iptables, the --source-port and --dport would be the keys to doing what I am trying to do. They would allow me to specify packets which match the source ports I am looking at and forward them to an internal host. IPChains/IPMasqadm don't have this functionality built in, right? Yes to the iptables part ... the PREROUTING table offers much more flexibility than prior firewalling implementations had. I think so, with respect to the ipchains/ipmasqadm part (at least I don't know how to do it with ipchains/ipmasqadm). This part is only a guess ... but you may be running into problems involving which side initiates the connection. If your PS2 initiates traffic from port 6000, that conenction will get NAT'd. If the remote end initiates a connection to port 6000, it will be forwarded to the PS2. You need (I think) to make ALL traffic from PS2 port 6000 look like it is coming from router port 6000, not router port 61XXX. I haven't actually tried to do this with the PREROUTING table, but I believe it can be done ... with the typical server restriction that such a setup can connect only a single PS2 to the Internet. It sounds like I will have to take this discussion off-line and do some research on my own. I appreciate all the help and explanations you guys have given. [old stuff deleted] Good luck. Keep us informed; this is likely to come up again. -- ---Never tell me the odds! Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED]
Re: [leaf-user] thttpd behind lrp
Sorry my mistake. INTERN_WWW_SERVER=192.168.1.203 is uncomented on lrp box the rest of changes below on thttpd box. Commands ran on thttpd box: ip addr 1: lo: LOOPBACK,UP mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope global lo 2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:35:20:e9 brd ff:ff:ff:ff:ff:ff inet 192.168.1.203/24 brd 192.168.1.255 scope global eth0 ip route 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.203 default via 192.168.1.254 dev eth0 net ipfilter list Chain input (policy ACCEPT: 59 packets, 6090 bytes): Chain forward (policy ACCEPT: 0 packets, 0 bytes): Chain output (policy ACCEPT: 43 packets, 3464 bytes): AutoFW: MarkFW: PortFW: netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:10230.0.0.0:* LISTEN tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN udp0 0 0.0.0.0:69 0.0.0.0:* raw0 0 0.0.0.0:1 0.0.0.0:* 7 raw0 0 0.0.0.0:6 0.0.0.0:* 7 Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node Path unix 0 [ ACC ] STREAM LISTENING /dev/log Thanks for help Andrey Charles Steinkuehler wrote: C. Dummy wrote: I'm trying to put thttpd behind lrp box on ip 192.168.1.203. I made lrp floppy with etc,ifconfig,local,modules,ramlog,root,thttpd and www-data packages. I edited syslinux.cfg so all packages load no errors and problems. I edited network.conf CONFIG_DNS=YES IF_AUTO=eth0 eth0_IPADDR=192.168.1.203 eth0_MASKLEN=24 eth0_DEFAULT_GW=192.168.1.254 eth1_IPADDR= eth1_MASKLEN= IPFILTER_SWITCH=none EXTERN_DHCP=NO INTERN_WWW_SERVER=192.168.1.203# Internal WWW server to make available (on lrp box) When I boot the floppy I don't get any errors and I can ping machines on LAN no problem. Thttpd and www-data are original files from packages(no changes made) I can't see anything from LAN using http://192.168.1.203(connecting... and nothing no message it just dies) or http://ip.binded.to.lrp.box(the connection was refused when attempting to contact ip.binded.to.lrp.box) can't see anything from outside either(the page cannot be displayed). Where is the problem? Thanks for help. I'm complete newbie with setting up web server sorry if this sounds silly. Andrey P.S.Ifconfig inet addr:192.168.1.203 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCASTRUNNING MULTICAST MTU:1500 Metric:1 Turn off the port-forwarding, which makes no sense in your situation. To do this, comment out the last line above, ie: # INTERN_WWW_SERVER=192.168.1.203 Other than that, if you need any more help, you should provide the output of the following commands, so we know more about your system setup: ip addr ip route net ipfilter liet netstat -ln --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] thttpd behind lrp
C. Dummy wrote: I should also show results from lrp box: ip addr: 1: lo: LOOPBACK,UP mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope global lo 2: eth0: BROADCAST,MULTICAST,PROMISC,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:80:c8:11:fc:96 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:60:08:a8:37:76 brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1 5: ppp0: POINTOPOINT,MULTICAST,NOARP,UP mtu 1492 qdisc pfifo_fast qlen 10 link/ppp inet 66.203.191.254 peer 66.203.188.1/32 scope global ppp0 ip route: 66.203.188.1 dev ppp0 proto kernel scope link src 66.203.191.254 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254 default via 66.203.188.1 dev ppp0 net ipfilter list: Chain input (policy DENY: 0 packets, 0 bytes): pkts bytes target prot opttosa tosx ifname mark outsize sourcedestination ports 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 5 - * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 13 - * 0 0 DENY icmp l- 0xFF 0x00 * 0.0.0.0/0 0.0.0.0/0 14 - * 0 0 DENY all l- 0xFF 0x00 ppp0 0.0.0.0 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 255.255.255.255 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 127.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 224.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 10.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 172.16.0.0/12 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 192.168.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 0.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 128.0.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 191.255.0.0/16 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 192.0.0.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 223.255.255.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 240.0.0.0/4 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 192.168.1.0/24 0.0.0.0/0 n/a 0 0 DENY all l- 0xFF 0x00 ppp0 66.203.191.254 0.0.0.0/0 n/a 0 0 REJECT all l- 0xFF 0x00 ppp0 0.0.0.0/0 127.0.0.0/8 n/a 0 0 REJECT all l- 0xFF 0x00 ppp0 0.0.0.0/0 192.168.1.0/24n/a 0 0 REJECT tcp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 * - 137 0 0 REJECT tcp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 * - 135 31 2418 REJECT udp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 * - 137 0 0 REJECT udp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 * - 135 11 528 REJECT tcp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 * - 138:139 0 0 REJECT udp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 * - 138 0 0 REJECT udp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 137:138 - * 0 0 REJECT udp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 135 - * 0 0 REJECT tcp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 137:139 - * 0 0 REJECT tcp -- 0xFF 0x00 ppp0 0.0.0.0/0 0.0.0.0/0 135 - * 0 0 ACCEPT tcp -- 0xFF 0x00 ppp0 216.171.153.128/25
[leaf-user] Thanks for Bering
To the Bering team et. al.: I very much appreciate the inclusion of the Last Updated field in the table at http://leaf.sourceforge.net/devel/jnilo/index.html. It certainly makes it much easier to keep track of the latest ssh packages. Thanks for Bering! Stephen --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] IPsec troubleshooting pointers
Hi, I'm trying to create a host subnet connection from an XP box to a subnet behind a Bering V1 rc4 NAT firewall. When the XP client pings an interface on the firewalled subnet, it returns one Negotiating IP security response followed by Request timed out for its other ping packets. Judging from /var/log/auth.log, the problem occurs after IPsec SA is established. I'm out of ideas to troubleshoot for what that problem might be. In producing ipsec barf, there is clearly a problem with there being no md5sum on the system, but shouldn't that be part of ipsec.lrp if it is required for operation? Grateful for any ideas auth.log, ipsec start up and ipsec barf are below. Thanks! Lee IPsec Windows XP to Bering/FreeS/WAN connection failures What auth.log shows when I attempt to connect: Nov 16 23:02:37 beringfirewall ipsec__plutorun: Starting Pluto subsystem... Nov 16 23:02:37 beringfirewall pluto[7363]: Starting Pluto (FreeS/WAN Version 1.98b) Nov 16 23:02:38 beringfirewall pluto[7363]: added connection description w2k-road-warriors Nov 16 23:02:38 beringfirewall pluto[7363]: listening for IKE messages Nov 16 23:02:38 beringfirewall pluto[7363]: adding interface ipsec0/eth0 192.168.2.253 Nov 16 23:02:38 beringfirewall pluto[7363]: loading secrets from /etc/ipsec.secrets Nov 16 23:03:50 beringfirewall pluto[7363]: packet from 192.168.2.1:500: ignoring Vendor ID payload Nov 16 23:03:50 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: responding to Main Mode from unknown peer 192.168.2.1 Nov 16 23:03:50 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: sent MR3, ISAKMP SA established Nov 16 23:03:51 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #2: responding to Quick Mode Nov 16 23:03:51 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #2: IPsec SA established then it pauses until eventually... Nov 16 23:04:54 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: ignoring Delete SA payload Nov 16 23:04:54 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: received and ignored informational message IPsec start up # /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.98b... ipsec_setup: Using /lib/modules/ipsec.o ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0) ipsec barf beringfirewall Sat Nov 16 23:12:05 UTC 2002 + _ version + + ipsec --version Linux FreeS/WAN 1.98b See `ipsec --copyright' for copyright information. + _ proc/version + + cat /proc/version Linux version 2.4.18 (root@samsung) (gcc version 2.95.4 20011002 (Debian prerelease)) #6 Sun Oct 20 15:06:22 CEST 2002 + _ proc/net/ipsec_eroute + + sort +3 /proc/net/ipsec_eroute sort: +3: No such file or directory + cat /proc/net/ipsec_eroute 0 192.168.3.0/24 - 192.168.2.1/32 = [EMAIL PROTECTED] + _ ip/route + + ip route 192.168.2.1 via 192.168.2.1 dev ipsec0 192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.254 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.253 192.168.2.0/24 dev ipsec0 proto kernel scope link src 192.168.2.253 default via 192.168.2.254 dev eth0 + _ proc/net/ipsec_spi + + cat /proc/net/ipsec_spi [EMAIL PROTECTED] IPIP: dir=out src=192.168.2.253 life(c,s,h)=addtime(495,0,0) [EMAIL PROTECTED] IPIP: dir=in src=192.168.2.1 life(c,s,h)=addtime(495,0,0) [EMAIL PROTECTED] ESP_3DES_HMAC_MD5: dir=out src=192.168.2.253 iv_bits=64bits iv=0x9ce1a78a77432e41 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(495,0,0) [EMAIL PROTECTED] ESP_3DES_HMAC_MD5: dir=in src=192.168.2.1 iv_bits=64bits iv=0xbd540ccc4e86f6d7 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(495,0,0) + _ proc/net/ipsec_spigrp + + cat /proc/net/ipsec_spigrp [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] + _ proc/net/ipsec_tncfg + + cat /proc/net/ipsec_tncfg ipsec0 - eth0 mtu=16260(1500) - 1500 ipsec1 - NULL mtu=0(0) - 0 ipsec2 - NULL mtu=0(0) - 0 ipsec3 - NULL mtu=0(0) - 0 + _ proc/net/pf_key + + cat /proc/net/pf_key sock pid socket next prev e n p sndbfFlags Type St c1fb93f0 7363 c118d75000 0 0 2 65535 3 1 + _ proc/net/pf_key-star + + cd /proc/net + egrep ^ pf_key_registered pf_key_supported pf_key_registered:satype socket pid sk pf_key_registered: 2 c118d750 7363 c1fb93f0 pf_key_registered: 3 c118d750 7363 c1fb93f0 pf_key_registered: 9 c118d750 7363 c1fb93f0 pf_key_registered:10 c118d750 7363 c1fb93f0 pf_key_supported:satype exttype alg_id ivlen minbits maxbits pf_key_supported: 2 14 3 0 160 160 pf_key_supported: 2 14 2
Re: [leaf-user] Simple autofw problem
On Saturday 16 November 2002 11:33, billy jacobs wrote: OK, what I thought would be a simple autofw problem turns out to be much more in-depth than I thought it would be. My slip up is that I assumed that I could forward based on the source port, and not the destination. So your attempting to forward an internal port to an external box. Hmmm, I can't say that this could actually work behind NAT. In all reality, many applications require use of specific application module in order to work with NAT. I don't know of one available for the PS2, but this would be your best bet in your situation. You are absolutely correct -- I am plowing new ground here, because there is very limited information on exactly how this service works. From all the documentation I found on the web (almost all from end-users), they are all using linksys routers (or similar devices), and their end-all answer is to put it on the DMZ. I was trying to avoid setting up any kind of DMZ setup off my router. The only IP-specific (and not router model specific) information I have found is to simply forward 6000-6999/udp to the PS2. Of course, they never mention if thats a source port or destination port, but going by the tcpdump trace, I can only assume its a source 6000-6999/udp. Again, lack of techincal specifics on how this service works is holding me back. Linksys routers allow a lot more services/traffic across them than any of the default LEAF firewall systems do. Likely this is one of them. It sounds like I will have to take this discussion off-line and do some research on my own. I appreciate all the help and explanations you guys have given. The help is no problem, I wish I knew more about this service so I could be more help. Google may be the best help for information at this time since I'm sure others have run into this and hopefully found a fix. Looking at your tcpdump output, Lynn's earlier reference to UDP port 4 was simply a slip of the tongue (or, more apt, the fingers). The 4 in your listings is the packet length, not the source or destination port. Yes, that was a slip I should really have had a clearer head when reading logs! Thx Ray, ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] Leaf LINCE
On Saturday 16 November 2002 04:57, Jaime Nebrera Herrera wrote: Hi, Great! The WP'ed SST dom would also be a great option (or CD-ROM). I'll love to check it out! Yes, could you give me the link for that DOM? http://www.sst.com/products.xhtml/mass_storage/58/SST58SD008 This archived post would also be of use. # start of archived post RE: [leaf-user] Compact Flash VS. disk-on-module VS. disk-on-chip ? Date: Mon, 21 Oct 2002 23:55:00 +0200 From: Erich Titl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi you may want to have a look at http://luna.think.ch/leaf/ADM it has a description how I modified the standard SST/Apacer ADM for write protection Erich end of previous post ## I dont think Linux (Leaf) can compete with such hardwarem but htey lack the flexibility. So we give you the swish army knife firewall :) You have plenty of features on it, and you decide wich ones to use. I wouldn't agree that LEAF products couldn't compete with Cisco/other products. Building a product-line, staff, and client base that Cisco has is the difficult part to duplicate on an enterprise level. I believe the cartoon Dilbert aptly explains a huge number of obstacals for something like LEAF in this setting. I'm sure many of us would contribute when and if we have the time! I know, its just we had a very sad experience with our LUG. Leaf is already a quite active development community. I must also admit that I haven't found my local LUG a desirable place to participate in very sad. LEAF is general active as a whole, but with many developers, it is simply a matter of having time to actually finish the projects we are currently working on (delays of 6 months of more are not unheard of). We have a volunteer that is working in this side. We might end up with a snort sensor or in other option with hogwash to make a inline IDS capable of dropping packages based on IDS signatures (only way to protect an exploitable server). I'll have to take your word for this, I haven't attempted anything along these lines. Yes I know, is the beaty of OS. We all try to compete in the same business but at the same time need to colaborate :) Here in Spain Barahona, one of the OS evangelists gies a little talk just of that and is really incredible. Also, is quite easier to get real knowledge because you end up knowing how the guts of it go. Exactly. It can save a commercial company a lot of resources and allow them time to work on specific options that individual developers would find impossible to accomplish without a full-time staff. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html 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] ipsec Bering
OK, now that we have a lot of information, let's go through what's here. # defaults for subsequent connection descriptions conn %default # How persistent to be in (re)keying negotiations (0 means very). keyingtries=0 # RSA authentication with keys from DNS. # authby=rsasig # leftrsasigkey=%dns # rightrsasigkey=%dns authby=secret left=ip.pub.lik.254 leftsubnet=192.168.0.0/24 leftfirewall=yes pfs=yes auto=add conn w2k-road-warriors right=%any Everything looks plausible here. I would get rid of the unnecessary connections. We truly wish you wouldn't change lines to hide your public ip address... You spend a lot of time doing it, you can make errors by hiding it, and we could get it if we wanted anyway. Changing it will not protect you from getting hacked if someone wanted to (and believe me, noone here has any interest in hacking you). I would also get rid of the *firewall=yes line, if the connection goes down, you will be forced to reboot the firewall to reconnect, which may be the problemsee later in the post. I have information on manually setting the firewall to allow the connections w/o this option at http://leaf.sourceforge.net/devel/guitarlynn/ipsec.txt and Tom has instruction for doing the same on http://www.shorewall.net or http://leaf.sourceforge.net/devel/jnilo/buipsec.html#AEN1436 . Nov 16 13:35:34 firewall ipsec_setup: Starting FreeS/WAN IPsec 1.98b... Nov 16 13:35:35 firewall ipsec_setup: Using /lib/modules/ipsec.o Nov 16 13:35:35 firewall ipsec_setup: KLIPS ipsec0 on ppp0 ip.pub.lik.254 peer ip.pub.lik.1/32 Nov 16 13:35:35 firewall ipsec_setup: ...FreeS/WAN IPsec started Nov 16 13:38:37 firewall kernel: Shorewall:FORWARD:REJECT:IN=ipsec0 OUT=eth1 SRC=62.147.151.223 DST=192.168.0.201 LEN=89 TOS=0x00 PREC=0x00 TTL=127 ID=60576 PROTO=UDP SPT=3309 DPT=161 LEN=69 OK, ipsec starts, then rejects a packet from the roadwarrior, we'll check for the error further down. + _ plog + + sed -n 2,$p /var/log/auth.log + egrep -i pluto + cat Nov 16 13:35:35 firewall ipsec__plutorun: Starting Pluto subsystem... Nov 16 13:35:35 firewall pluto[24215]: Starting Pluto (FreeS/WAN Version 1.98b) Nov 16 13:35:35 firewall pluto[24215]: including X.509 patch (Version 0.9.13) Nov 16 13:35:35 firewall pluto[24215]: Could not change to directory '/etc/ipsec.d/cacerts' Nov 16 13:35:35 firewall pluto[24215]: Could not change to directory '/etc/ipsec.d/crls' Nov 16 13:35:35 firewall pluto[24215]: loaded my default X.509 cert file '/etc/x509cert.der' (7 bytes) Nov 16 13:35:35 firewall pluto[24215]: file coded in unknown format, discarded Nov 16 13:35:35 firewall pluto[24215]: OpenPGP certificate file '/etc/pgpcert.pgp' not found It appears to be trying to load a x509 cert, If I remember correctly the Bering ipsec package(s) offer seperate packages for use of x509 certs, but this could be a possible problem. I know Dachstein offers an add-on package for x509 certs. Nov 16 13:35:36 firewall pluto[24215]: added connection description sample Nov 16 13:35:37 firewall pluto[24215]: added connection description w2k-road-warriors Nov 16 13:35:37 firewall pluto[24215]: listening for IKE messages Nov 16 13:35:37 firewall pluto[24215]: adding interface ipsec0/ppp0 ip.pub.lik.254 Nov 16 13:35:37 firewall pluto[24215]: loading secrets from /etc/ipsec.secrets Nov 16 13:38:36 firewall pluto[24215]: packet from 62.147.151.223:500: ignoring Vendor ID payload Nov 16 13:38:36 firewall pluto[24215]: w2k-road-warriors[1] 62.147.151.223 #1: responding to Main Mode from unknown peer 62.147.151.223 Nov 16 13:38:36 firewall pluto[24215]: w2k-road-warriors[1] 62.147.151.223 #1: Peer ID is ID_IPV4_ADDR: '62.147.151.223' Nov 16 13:38:36 firewall pluto[24215]: w2k-road-warriors[1] 62.147.151.223 #1: sent MR3, ISAKMP SA established Nov 16 13:38:37 firewall pluto[24215]: w2k-road-warriors[1] 62.147.151.223 #2: responding to Quick Mode Here your w2k-road-warriors tunnel comes up successfully, all that has not happened here is the successful transmission of information across the tunnel. Nov 16 13:38:37 firewall pluto[24215]: w2k-road-warriors[1] 62.147.151.223 #2: route-client output: RTNETLINK answers: Network is unreachable Nov 16 13:38:37 firewall pluto[24215]: This is the indication of the problem. For some reason, the network becomes unreachable and/or the tunnel bombs out. Why this is happening is the only unclear problem, I can't say clearly and monitoring tcpdump may be the only good way of locating exactly why. Possibly your ISP is blocking the packets or the road-warrior kills the connection. The rest of the log indicates that the boxes attempt to restart the tunnel, but fail. This is what normally happens after a dropped tunnel with the *firewall=yes option and why I do not suggest using this option. I hope this helps, ~Lynn -- ~Lynn Avants aka
Re: [leaf-user] IPsec troubleshooting pointers
On Saturday 16 November 2002 15:49, Lee Kimber wrote: Hi, I'm trying to create a host subnet connection from an XP box to a subnet behind a Bering V1 rc4 NAT firewall. When the XP client pings an interface on the firewalled subnet, it returns one Negotiating IP security response followed by Request timed out for its other ping packets. Judging from /var/log/auth.log, the problem occurs after IPsec SA is established. I'm out of ideas to troubleshoot for what that problem might be. Likely this is a incorrect option set up on the WinXP client. The Bering Users manual ( http://leaf.sourceforge.net/devel/jnilo/buipsec.html#AEN1436 ) has instructions for Win2K, if they help. Possibly Chad Carr or someone else that has connected with WinXP could help here. In producing ipsec barf, there is clearly a problem with there being no md5sum on the system, but shouldn't that be part of ipsec.lrp if it is required for operation? This should not be required. What auth.log shows when I attempt to connect: Nov 16 23:02:37 beringfirewall ipsec__plutorun: Starting Pluto subsystem... Nov 16 23:02:37 beringfirewall pluto[7363]: Starting Pluto (FreeS/WAN Version 1.98b) Nov 16 23:02:38 beringfirewall pluto[7363]: added connection description w2k-road-warriors Nov 16 23:02:38 beringfirewall pluto[7363]: listening for IKE messages Nov 16 23:02:38 beringfirewall pluto[7363]: adding interface ipsec0/eth0 192.168.2.253 Nov 16 23:02:38 beringfirewall pluto[7363]: loading secrets from /etc/ipsec.secrets Nov 16 23:03:50 beringfirewall pluto[7363]: packet from 192.168.2.1:500: ignoring Vendor ID payload Nov 16 23:03:50 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: responding to Main Mode from unknown peer 192.168.2.1 Nov 16 23:03:50 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: sent MR3, ISAKMP SA established Nov 16 23:03:51 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #2: responding to Quick Mode Nov 16 23:03:51 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #2: IPsec SA established Hmm it appears to be extremly strange to be connecting to rfc1918 class address via the internet (or even having Shorewall accept anything from this address). Could we get some more information on the WAN link? then it pauses until eventually... Nov 16 23:04:54 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: ignoring Delete SA payload Nov 16 23:04:54 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: received and ignored informational message Apparently Bering didn't approve the information sent through the tunnel. Sounds like their may be a configuration problem on either of the two boxes. IPsec start up # /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.98b... ipsec_setup: Using /lib/modules/ipsec.o ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0) This is a problem. I believe you will have to change this option. This is noted in the Bering User Manual: Quote You must not turn on route filtering for any interfaces involved in ipsec. The Bering recommended way to turn this off is to use the /etc/network/options file and change the spoofprotect parameter to no + ip route 192.168.2.1 via 192.168.2.1 dev ipsec0 192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.254 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.253 192.168.2.0/24 dev ipsec0 proto kernel scope link src 192.168.2.253 default via 192.168.2.254 dev eth0 This appears to be a very unclear test system. Using a 10./8 on the WAN would clarify a lot between WAN and LAN networks. Using the same net block addressing makes it much harder to see what is exactly going on. # How persistent to be in (re)keying negotiations (0 means very). keyingtries=0 # RSA authentication with keys from DNS. # authby=rsasig # leftrsasigkey=%dns # rightrsasigkey=%dns # Following added by Lee just as above 3 commented by Lee authby=secret left=192.168.2.253 leftsubnet=192.168.3.0/24 leftfirewall=yes pfs=yes auto=add Get rid of the leftfirewall-yes entry, it will not allow a reconnection if a tunnel drops w/o a reboot. It will not be needed if Shorewall is configured correctly for ipsec. + sed -n 210,$p /var/log/syslog + egrep -i ipsec|klips|pluto + cat Nov 16 23:02:36 beringfirewall ipsec_setup: Starting FreeS/WAN IPsec 1.98b... Nov 16 23:02:36 beringfirewall ipsec_setup: Using /lib/modules/ipsec.o Nov 16 23:02:37 beringfirewall ipsec_setup: KLIPS ipsec0 on eth0 192.168.2.253/24 broadcast 192.168.2.255 Nov 16 23:02:37 beringfirewall ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work Nov 16 23:02:37 beringfirewall ipsec_setup:
Re: [leaf-user] IPsec troubleshooting pointers
Likely this is a incorrect option set up on the WinXP client. The Bering Users manual ( http://leaf.sourceforge.net/devel/jnilo/buipsec.html#AEN1436 ) has instructions for Win2K, if they help. Possibly Chad Carr or someone else that has connected with WinXP could help here. Yeah, I have been through it pretty thoroughly (and I did find config mistakes that I'd made ;-)). What auth.log shows when I attempt to connect: Nov 16 23:02:37 beringfirewall ipsec__plutorun: Starting Pluto subsystem... Nov 16 23:02:37 beringfirewall pluto[7363]: Starting Pluto (FreeS/WAN Version 1.98b) Nov 16 23:02:38 beringfirewall pluto[7363]: added connection description w2k-road-warriors Nov 16 23:02:38 beringfirewall pluto[7363]: listening for IKE messages Nov 16 23:02:38 beringfirewall pluto[7363]: adding interface ipsec0/eth0 192.168.2.253 Nov 16 23:02:38 beringfirewall pluto[7363]: loading secrets from /etc/ipsec.secrets Nov 16 23:03:50 beringfirewall pluto[7363]: packet from 192.168.2.1:500: ignoring Vendor ID payload Nov 16 23:03:50 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: responding to Main Mode from unknown peer 192.168.2.1 Nov 16 23:03:50 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #1: sent MR3, ISAKMP SA established Nov 16 23:03:51 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #2: responding to Quick Mode Nov 16 23:03:51 beringfirewall pluto[7363]: w2k-road-warriors[1] 192.168.2.1 #2: IPsec SA established Hmm it appears to be extremly strange to be connecting to rfc1918 class address via the internet (or even having Shorewall accept anything from this address). Could we get some more information on the WAN link? This is a wireless link running from my main router - a Dachstein box - to a subnet that is hanging off this new Bering box. So the Bering router is a on one of the subnets of the Dachstein box (192.168.2.0/24). This link and both routers work great. The XP box is a laptop that is also on the 192.168.2.0/24 subnet and is able to ssh into boxes hanging off either of the routers. Shorewall is set to ignore RFC1918 on the Bering box in the Shorewall interface set up. (Shorewall is not running on the Dachstein box) IPsec start up # /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.98b... ipsec_setup: Using /lib/modules/ipsec.o ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0) This is a problem. I believe you will have to change this option. This is noted in the Bering User Manual: Quote You must not turn on route filtering for any interfaces involved in ipsec. The Bering recommended way to turn this off is to use the /etc/network/options file and change the spoofprotect parameter to no Yeah, I have done that. The messages you are seeing are occurring despite the spoofprotect option being set to no. IIRC, IPsec seems to return this message regardless. + ip route 192.168.2.1 via 192.168.2.1 dev ipsec0 192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.254 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.253 192.168.2.0/24 dev ipsec0 proto kernel scope link src 192.168.2.253 default via 192.168.2.254 dev eth0 This appears to be a very unclear test system. Using a 10./8 on the WAN would clarify a lot between WAN and LAN networks. Using the same net block addressing makes it much harder to see what is exactly going on. I'm sitting behind DSL that is NATted by the ISP. My Dachstein router breaks that up into a bunch of of 192.168.x.x/24 subnets, all of which work fine. One of of the subnets is 192.168.2.0/24, on which the Bering box sits. The Bering box hides a single 192.168.3.0/24 subnet. Boxes on that subnet are able to reach the Internet fine using the Bering box as their first hop, then the Dachstein box and then whatever my ISP has imposed. I run it like this because the servers can't be near the main DSL router for space and noise reasons. They sit on the 192.168.3.0/24 subnet hosts in a different room. # How persistent to be in (re)keying negotiations (0 means very). keyingtries=0 # RSA authentication with keys from DNS. # authby=rsasig # leftrsasigkey=%dns # rightrsasigkey=%dns # Following added by Lee just as above 3 commented by Lee authby=secret left=192.168.2.253 leftsubnet=192.168.3.0/24 leftfirewall=yes pfs=yes auto=add Get rid of the leftfirewall-yes entry, it will not allow a reconnection if a tunnel drops w/o a reboot. It will not be needed if Shorewall is configured correctly for ipsec. Thanks, I didn't know that and will try it. + sed -n 210,$p /var/log/syslog + egrep -i ipsec|klips|pluto + cat Nov 16 23:02:36 beringfirewall ipsec_setup: Starting FreeS/WAN IPsec 1.98b... Nov 16
