Re: [leaf-user] subnet-to-subnet simulation problem
On Sunday 29 September 2002 05:08, Vic Berdin wrote: >VPN1-CLI > > |eth0: 192.168.4.1 > |gw:192.168.4.200 > | > | > |eth1: 192.168.4.200 > |gw:192.168.2.1 > > VPN1 BOX >From the look of things, your using Dachstein, so I will assume this. Looks pretty unusual to use eth1 as an external interface, this can bork the networking pretty good with Dachstein in the default setup. > ip_masq_ipsec 7328 0 (unused) DO NOT USE the ipsec module with Dachstein it will bork everything up with the ipsec-kernel. The module is only used for pass-through with Dachstein. > Jul 30 03:42:30 SR3K-VPN1 Pluto[1574]: packet from > 192.168.2.200:61070: initial Main Mode message received on > 192.168.2.1:500 but no connection has been authorized Looks like your keys/naming isn't right in ipsecrets and the point of failure unless having the ipsec module loaded is messing the connection up here (good possibility). -- ~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: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] vpn help, link included
On Sun, 29 Sep 2002, Matthew Schalit wrote: > In addition to what JO said, I'd put the printer on > a Jetdirect and make life easy. As someone with a printer with a Jetdirect, I highly recommend having a single computer act as print server anyway... spooling performance can suck remarkably if you don't. > Be sure to include > it's ip addy/name in DNS and /etc/hosts everywhere. ... or use an internal DNS so you don't have to keep up with the /etc/hosts file proliferation. [...] --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- 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] web interface
On Saturday 28 September 2002 15:38, Ping Kwong wrote: > I was looking at other solutions for a client when I stumbled upon > Smoothwall (http://www.smoothwall.org). There has been past > discussions about some sort of administrative web interface, I > thought based on the screenshots that it was very slick and intuitive > for users. I'm well aware of the blatant ripoff of IPCop.org even > though it's claimed to be a fork of the Smoothwall project. So my > question is, would using some of the web interface that is available > to this project be a > consideration as a starting point? Not very likely being that Smoothwall is forked from Coyote and what we have in mind is a total re-write of the present configuration system included with any present variant. We aren't looking at simply adding a web-interface as much as building a new system that offers an optional web-interface. I don't know of any available web-interfaces that come anywhere near the scope we are intending. Thanks for the direction though, hopefully we can find something OSS that would save some coding! > On another note, does anyone have a recent copy of squid.lrp and > squidguard.lrp and/or DansGuardian? I think David D has fairly recent Squid and Squidguard packages in the Oxygen section and/or CVS. There is also Junkbuster available at the same location. -- ~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: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] vpn help, link included
On Sunday 29 September 2002 02:02, junkmail wrote: > Hello, > > I have what I think would be a VPN task for maybe a LEAF box I > have set up severl LEAF as a simple firewall and think they are > terrific... A .jpg is worth a thousand words so... if any of you > could point me in the right direction and take a look at the layout I > have in mind I would be greatfull for any suggestions / starting > points... > > here is the layout > http://home.attbi.com/~crackerjack31/help.jpg > thanks > Gary. IPSec would work for this if you don't feel like tunneling the services via ssh, stunnel, or zebedee. The big hitch is going to be name resolution on the LAN sides unless you can get by with ip addy only resolution. Check http://leaf.sourceforge.net/devel/guitarlynn/ipsec.txt or the ipsec section in the Bering Users Manual. -- ~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: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] sshd
Date: Sun, 29 Sep 2002 14:15:14 +0200 To: [EMAIL PROTECTED] From: Erich Titl <[EMAIL PROTECTED]> Subject: Re: [leaf-user] sshd >Steve wrote the following at 08:27 29.09.2002: >>I am trying to set up sshd in Bering. >>I have loaded the sshd.lrp and libz.lrp packaged and have generated my >>keys ,but when sshd is run it complaines that is cannont find >>libnsl.so.1 file. I've done a few searches and can not find where this >>file might be or where I can download it from. >>Any suggstions? >>Regards. >Where did you take your sshd.lrp from. I have sshd on bering running >on bering without libnsl. IIRC I got mine from Jacques Nilo's packages > >Erich got it from the same site. I have tried reloading several times all with the same result. --- 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] vpn help, link included
We are talking about products like Windows Terminal Services or Citrix Metaframe here? Depending on your security needs you could do this without using a VPN. Assuming both client and server are behind NATting firewalls, you only have to port-forward rdp (or ICA) traffic to the terminal server. RDP and ICA both allow you to enable encryption on the data stream. mapping local printers is a basic application-level capability of both TS implementations. Sjaak > > I have what I think would be a VPN task for maybe a LEAF box I have set > up severl LEAF as a simple firewall and think they are terrific... > A .jpg is worth a thousand words so... if any of you could point me in the > right direction and take a look at the layout I have in mind I would be > greatfull for any suggestions / starting points... > > here is the layout > http://home.attbi.com/~crackerjack31/help.jpg > thanks > Gary. > > > --- > 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 > --- 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] trouble with ipip encapsulation tunnels (well, unexpected behavior, really)
On Sun, 29 Sep 2002 12:37:42 -0700 "Matthew Schalit" <[EMAIL PROTECTED]> wrote: > > Hi Chad, >Hope things are working out. > >I like your diagram, and then again I don't. > But maybe it's just me, I don't know, but I can't > understand it as much as I need to. I admire your > attempt, though, because it was properly spaced, > readable, and darn good for what it was. Thanks very much for your patience. This diagram is trying to detail something that doesn't happen usually in nature, which is the existence of a mobile node on the "wrong" subnet, with two computers in cooperation (home agent and foreign agent) attempting to get packets to it. I'll try again: 172.24.8.1/24172.24.20.1/22 ^^__ | switch |---| router |---| switch | || || |__| | | | __|__|__|___ || | | | | | home agent | | foreign agent | | mobile node | || |___| |_| 172.24.8.99/24 172.24.20.104/22 172.24.8.24/24 All links are CAT5 ethernet. Home agent, foreign agent and mobile node are each separate, regular PC hosts with one NIC (eth0) and one IP address each. The titles "home agent" and "foreign agent" are simply relative to the mobile node. The home agent "catches" packets destined for the mobile node (via proxy arp), tunnels them through the router to the foreign agent, who has agreed to detunnel them and deliver them (via the mobile node's known _hardware_ address) to the mobile node. The mobile node really "belongs" on the same network as the home agent. The foreign agent is not a bridge - it knows the ethernet address of the mobile node and has a host route to it that indicates that it is on the same link (see below). The IP-in-IP tunnel is between the home agent and the foreign agent. I have verified that the packets routing between them are properly formed and have correct checksums in all the right places. I have verified that the foreign agent is receiving the tunneled packet on eth0 by logging all packets seen on PREROUTING and INPUT using the following rules: iptables -A PREROUTING -t mangle -j LOG iptables -A INPUT -t mangle -j LOG I also see the de-tunneled packet arriving on tunl0 via the PREROUTING chain. I have also added the following rule to track packets on the FORWARD chain, which is where I think the de-tunneled packet should go next. iptables -F FORWARD -t mangle -j LOG I see nothing. I am sorry I do not have the logs at home. I can send them on Monday. The following are reconstructions of the setup on the foreign agent to the best of my memory. "ip addr sh" on foreign agent: 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:60:b0:45:f6:d8 brd ff:ff:ff:ff:ff:ff inet 172.24.20.104/22 brd 172.24.23.255 scope global eth0 19: tunl0@NONE: mtu 1480 qdisc noop link/ipip 0.0.0.0 brd 0.0.0.0 inet 172.24.8.104/32 scope global tunl0 "ip route sh" on foreign agent: 172.24.8.24 dev eth0 scope link 172.24.20.0/22 dev eth0 proto kernel scope link src 172.24.20.104 default via 172.24.20.1 dev eth0 "ip neigh sh" on foreign agent 172.24.8.24 dev eth0 lladdr 00:00:0d:2f:0f:0b nud permanent 172.24.20.1 dev eth0 lladdr 00:d0:b7:1c:5a:90 nud reachable "ip -s tunnel sh" on foreign agent tunl0: ip/ip remote any local any ttl inherit nopmtudisc RX: PacketsBytesErrors CsumErrs OutOfSeq Mcasts 5 580 0 000 TX: PacketsBytesErrors DeadLoop NoRoute NoBufs 0 00 000 The packet and byte count increment properly when packets are received. The byte count increases by the size of the _inner_ packet. Again, I appreciate your time and patience. I hope these drawings and material are a little clearer; it is by nature a bit of a weird setup. I feel that I have sort of covered all of the bases on this one and still have a disconnect. My next step is to get inside the kernel itself and try and figure out where the packets are getting dropped and why - sort of an inside-out approach, I guess. Thanks. -- Chad Carr [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
Re: [leaf-user] vpn help, link included
In addition to what JO said, I'd put the printer on a Jetdirect and make life easy. Be sure to include it's ip addy/name in DNS and /etc/hosts everywhere. I don't like to rely on a computer as a print server, but whatever works and saves time/$$. Is there any NAT going on, and can IPSec handle that? I think the ESP flavor of IPSEc can, but it looks like your connecting subnet to subnet, and doesn't that disallow ESP/NAT? Lynn was working on an IPSec mini-HOWTO and it's good stuff. Oh well. Not my area really, but I'm rolling out a host-to-subnet (roadwarrior) that's easier. Regards, Matthew Joey Officer wrote: > First thing you need to do is to make sure that the workstation on the B > side can print to the printer. Once that is done, everything else is a > piece of cake. Look over the IPSec documentation, that is what you want to > put in place. I have almost an identical setup here at the office, and it > works fine. Let me know if you need some specific help. > > BTW, I'm running Dachstein-CD Based installs with IPSec 1.91. Took me a few > days to fully understand what it was I was doing, but I've got it down now. > Atleast that part. > > Joey Officer > Martin Apparatus, Inc. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of junkmail > Sent: Sunday, September 29, 2002 2:02 AM > To: [EMAIL PROTECTED] > Subject: [leaf-user] vpn help, link included > > Hello, > > I have what I think would be a VPN task for maybe a LEAF box I have set > up severl LEAF as a simple firewall and think they are terrific... > A .jpg is worth a thousand words so... if any of you could point me in the > right direction and take a look at the layout I have in mind I would be > greatfull for any suggestions / starting points... > > here is the layout > http://home.attbi.com/~crackerjack31/help.jpg > thanks > Gary. --- 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] trouble with ipip encapsulation tunnels (well,unexpected behavior, really)
Hi Chad, Hope things are working out. I like your diagram, and then again I don't. But maybe it's just me, I don't know, but I can't understand it as much as I need to. I admire your attempt, though, because it was properly spaced, readable, and darn good for what it was. But what I need is: 1) a box symbolizing each router, switch, hub, and host. 2) then a line into each box for each nic, (the line representing your CAT5) 3) then the ipaddy/mask of each nic written next to the line. 4) If the internet comes into play, label that too. I'll make an attempt to redo your drawing, but plz fix it and then paste in your syslog trail of the packet and include ip addr show ip route show and any other ip tunnel show thing you can think of that's relevant. Roger. 172.24.8.???/24 __ \ __172.24.20.???/22 | ||| |home agent|| LEAF |, <--subnet 172.24.20.0/22 |__|||| 172.24.8.99/24 | | subnet 172.24.8.0/24|172.24.20.104/22 _|___ | | |foreign agent| | (a host) | |_| | ???.???.???.???/24 ? ? <--- What's this link, cat5? ? ? | 172.24.8.24/24 |__ | | Is this another host?---> |mobile node| |___| You said the foreign agent has only one nic. So it's a computer. Is the mobile node a differnt computer? If so, how does it connect to the foreign agent. If the link is cat5, then the foreign agent has to have 2 nics and be a bridge, essentially. Maybe the the mobile node is a virtual extension of the foreign agent, and there's only the computers in the scenario: 1) Home computer 2) Leaf router 3) Foreign computer Is that what's happening Well I'll stop for now :) Plz check the addys/masks and fill in the blanks. Matthew Chad Carr wrote: > On Fri, 27 Sep 2002 08:22:02 -0700 > "Matthew Schalit" <[EMAIL PROTECTED]> wrote: > > >>Chad Carr wrote: >> >>>Hello routing and tunneling guys and gals! I have a tunneling quandry >>>for ye. >>> >>>I am doing an implementation of mobile ip and have finally solidified >>>all of the protocol bits to implement a foreign agent, and have come >>>to the part where I need to accept ip-in-ip tunneled packets for a >>>mobile node, detunnel them, and deliver them to him. I am using the >>>kernel ipip.o module for this, and have configured the tunnel as >>>follows: >>> >>>__ _ ___ >>> | | | || | >>> |home agent|===(router)===>|foreign agent|--->|mobile node| >>> |__| |_||___| >>> >>> >>>home agent ip- 172.24.8.99 >>>foreign agent ip - 172.24.20.104 >>>mobile node ip - 172.24.8.24 (on the foreign network) >> >> >> >>I question the ip addresses below >> >> >> >> >> >>>I am not in control of the home agent, but I have verified with a >>>sniffer that he is sending me well-formed ip-in-ip packets for the >>>mobile node, plus he works with anothe foreign agent that I have, so >>>he is not the problem. >>> >>>foreign agent configuration: >>> >>># bring up tunnel device >>>ip tunnel add mode ipip # (default tunnel tunl0; local *->remote *) >>> >>># add static arp table entry since mobile node can't reply >>>ip neigh add 172.24.8.24 lladdr 00:00:0d:2f:a0:b0 dev eth0 nud perm >>> >>># add static host route >>>ip route add 172.24.8.24 dev eth0 >> >> >> >> >>Is 172.24.8.24 really connected to eth0 or is the it eth1? > > > My email was unclear on this. There is really only one interface in the > foreign agent. The picture should look more like this: > >___ > | | > |mobile node|<-| > __|___| | >| | | | >|home agent|===(router)===| _
Re: [leaf-user] multiple IP for single NIC
On Saturday 28 September 2002 05:08 am, Erich Titl wrote: > Hi folks > > This is going to be trivial for some of you. My firewall is an old laptop > which I like for its low power consumption. Of course it is limited to 2 > PCMCIA interfaces, so I want to use multiple IP addresses on the inside to > al least logically build a DMZ. I have unfortunately not been able to find > the correct syntax for the interface file to assign 2 different IP > adresses. Once this is established I will have to set up shorewall to > direct some ports to that locical interface. > > Do I have to use 2 different iface stanzas in the interface file like: > > iface eth1:0 inet static > address 194.124.158.99 > masklen 24 > broadcast 194.124.158.255 > > iface eth1:1 inet static > address 192.168.1.1 > masklen 24 > broadcast 192.168.1.255 > > Thanks for pointers > > Erich > > THINK > Püntenstrasse 39 > 8143 Stallikon > mailto:[EMAIL PROTECTED] > PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 > > > > --- > 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 Exactly. -C --- 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] trouble with ipip encapsulation tunnels (well, unexpected behavior, really)
On Fri, 27 Sep 2002 08:22:02 -0700 "Matthew Schalit" <[EMAIL PROTECTED]> wrote: > Chad Carr wrote: > > Hello routing and tunneling guys and gals! I have a tunneling quandry > > for ye. > > > > I am doing an implementation of mobile ip and have finally solidified > > all of the protocol bits to implement a foreign agent, and have come > > to the part where I need to accept ip-in-ip tunneled packets for a > > mobile node, detunnel them, and deliver them to him. I am using the > > kernel ipip.o module for this, and have configured the tunnel as > > follows: > > > > __ _ ___ > >| | | || | > >|home agent|===(router)===>|foreign agent|--->|mobile node| > >|__| |_||___| > > > > > > home agent ip- 172.24.8.99 > > foreign agent ip - 172.24.20.104 > > mobile node ip - 172.24.8.24 (on the foreign network) > > > > I question the ip addresses below > > > > > > > > I am not in control of the home agent, but I have verified with a > > sniffer that he is sending me well-formed ip-in-ip packets for the > > mobile node, plus he works with anothe foreign agent that I have, so > > he is not the problem. > > > > foreign agent configuration: > > > > # bring up tunnel device > > ip tunnel add mode ipip # (default tunnel tunl0; local *->remote *) > > > > # add static arp table entry since mobile node can't reply > > ip neigh add 172.24.8.24 lladdr 00:00:0d:2f:a0:b0 dev eth0 nud perm > > > > # add static host route > > ip route add 172.24.8.24 dev eth0 > > > > > Is 172.24.8.24 really connected to eth0 or is the it eth1? My email was unclear on this. There is really only one interface in the foreign agent. The picture should look more like this: ___ | | |mobile node|<-| __|___| | | | | | |home agent|===(router)===| _ | |__| |===>| || |foreign agent|| |_| subnet 172.24.8.0/24 subnet 172.24.20.0/22 That is, the mobile node and the foreign agent are on the same segment on the right-hand side of the router (the foreign agent is on the "right" segment, conceptually, and the mobile node is on the "wrong" segment, conceptually). There is a unicast ip-in-ip tunnel between the home agent and the foreign agent (on different segments; the router is needed to get packets back and forth on the tunnel between home agent and foreign agent) > > > > > I have verified the following: > > > > 1) The packets are getting delivered to the foreign agent; > > 2) The packets are being accepted by tunl0 and processed; > > 3) They are the expected size (the size of the inner ip packet); > > 4) They are not being delivered anywhere outside the box. > > > > But it seems like you haven't enabled logging all packets on > the foreign agent that come from the home agent or are destined > for the home agent. I find adding those types of firewall rules > essential to these routing jobs. Seriously. Log them packys. > > Then you'd see if the traffic is even moving out eth0 on the > foreign agent on its way to the remote node. Okay, I added the following rules to the firewall: iptables -A PREROUTING -t mangle -j LOG iptables -A INPUT -t mangle -j LOG iptables -A FORWARD-t mangle -j LOG So, new information: I see the tunneled packet coming in on both PREROUTING and INPUT on interface eth0, as it should be. I then see the _unwrapped_ packet coming in on INPUT on interface tunl0. The destination address of the unwrapped packet is 172.24.8.24. I figure, according to the rules in Rusty's unreliable guide on iptables, that the packet should hit the FORWARD chain next (since it is not destined to the foreign agent itself), but is somehow failing some internal sanity check and getting dropped. After PREROUTING, a packet should hit either INPUT or FORWARD, correcto? > > > I figure the following bits are true: > > > > The foreign agent is holding a copy of the ip packet addressed to the > > mobile node. He may do one of the following: a) assume that the > > packet is for delivery on the local link, look up the ip in the > > arp table, and deliver it to the mobile node b) hit the routing table > > again and see the host route, see that it is directly connected, > > look up the ip in the arp table, and deliver it to the mobile > > node. c) drop the packet > > > > Obviously, given the way I have configured the box, I believe that "b" > > should be what is happening. However
RE: [leaf-user] vpn help, link included
First thing you need to do is to make sure that the workstation on the B side can print to the printer. Once that is done, everything else is a piece of cake. Look over the IPSec documentation, that is what you want to put in place. I have almost an identical setup here at the office, and it works fine. Let me know if you need some specific help. BTW, I'm running Dachstein-CD Based installs with IPSec 1.91. Took me a few days to fully understand what it was I was doing, but I've got it down now. Atleast that part. Joey Officer Martin Apparatus, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of junkmail Sent: Sunday, September 29, 2002 2:02 AM To: [EMAIL PROTECTED] Subject: [leaf-user] vpn help, link included Hello, I have what I think would be a VPN task for maybe a LEAF box I have set up severl LEAF as a simple firewall and think they are terrific... A .jpg is worth a thousand words so... if any of you could point me in the right direction and take a look at the layout I have in mind I would be greatfull for any suggestions / starting points... here is the layout http://home.attbi.com/~crackerjack31/help.jpg thanks Gary. --- 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 --- 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] sshd
Steve wrote the following at 08:27 29.09.2002: >I am trying to set up sshd in Bering. >I have loaded the sshd.lrp and libz.lrp packaged and have generated my >keys ,but when sshd is run it complaines that is cannont find >libnsl.so.1 file. I've done a few searches and can not find where this >file might be or where I can download it from. >Any suggstions? >Regards. Where did you take your sshd.lrp from. I have sshd on bering running on bering without libnsl. IIRC I got mine from Jacques Nilo's packages Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- 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
[leaf-user] subnet-to-subnet simulation problem
Hello everyone, This is actually a freeswan VPN query, so I'm sorry if I had to post this query here also. But I do know that most of you are experts in the VPN field, hence, here goes... I've been trying to do a subnet-to-subnet VPN using my LEAF based routers without success. My setup involves another LEAF machine acting as a virtual internet between the two VPN boxes. Here's a diagram of my setup: VPN1-CLI |eth0: 192.168.4.1 |gw:192.168.4.200 | | |eth1: 192.168.4.200 |gw:192.168.2.1 VPN1 BOX |eth0: 192.168.2.1 |gw: 192.168.2.200 | | |eth1: 192.168.2.200 |gw: 192.168.1.200 ROUTEReth0: 192.168.1.200 |eth2: 192.168.3.200 |gw:192.168.1.200 | | |eth0: 192.168.3.1 |gw:192.168.3.200 VPN2 BOX |eth1: 192.168.5.200 |gw:192.168.3.1 | | |eth0: 192.168.5.1 |gw:192.168.5.200 VPN2-CLI My VPN and ROUTER machines are LEAF/LRP 2.2.19 based, while the VPN-CLI client machines are Win98 PCs. My problem is that, I cannot 'ping' 192.168.4.1 from 192.168.5.1 and vise versa. Upon running 'ipsec look' on either side, I get a 'trap' status instead of a tunnel. SR3K-VPN1 Tue Jul 30 04:02:27 UTC 2002 192.168.4.0/24 -> 192.168.5.0/24 => %trap (0) ipsec0->eth0 mtu=16260(1500)->1500 Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 0 ipsec0 I believe there's nothing wrong with my network setup and ipchaining / routing rules as I am able to 'ping' VPN1 BOX from VPN2-CLI, and 'ping' VPN2 BOX from VPN1-CLI. I can also 'ping' VPN1 from VPN2 BOX, and vise versa. Below are some of the listings in my 'ipsec barf' result. I'm currently employing a very lame ipchain rule set just to see this work. Both of my VPN machines are currently using the same set of rules with respect to their network settings. I also tried allowing ipsec protocols to pass thru ROUTER's internal networks thinking it may be needed not! What else am I missing here? TIA - Vic = SR3K-VPN1 Tue Jul 30 03:43:58 UTC 2002 + _ + + ipsec --version Linux FreeS/WAN 1.91 See `ipsec --copyright' for copyright information. + _ + + cat /proc/net/ipsec_eroute 0 192.168.4.0/24 -> 192.168.5.0/24 => %trap + _ + + cat /proc/net/ipsec_spi + _ + + cat /proc/net/ipsec_spigrp + _ + + netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 0 ipsec0 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 0 eth0 + _ + + 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 + _ + + cat /proc/net/pf_key sock pid socket next prev e n p sndbfFlags Type St c7278680 1574 c54643b000 0 0 2 32767 3 1 + _ + + cd /proc/net + egrep ^ pf_key_registered pf_key_supported pf_key_registered:satype socket pid sk pf_key_registered: 2 c54643b0 1574 c7278680 pf_key_registered: 3 c54643b0 1574 c7278680 pf_key_registered: 9 c54643b0 1574 c7278680 pf_key_registered:10 c54643b0 1574 c7278680 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 + _ + + cd /proc/sys/net/ipsec + egrep ^ debug_ah debug_eroute debug_esp debug_ipc
