[CLUE-Tech] Marginally OT: VPN client

[Sean LeBlanc]

On 08-13 09:24, Frank Whiteley wrote:
> Also, any chance you are routing a public subnet and private IP space on
> this C678 using eth0 and vipX?  Is it in routed or bridged mode?
> 
> Frank Whiteley
> Greeley

Thanks for all the input, guys.

I'm still not having any luck with this. The admin suggested that I try
removing the Linksys from the equation. I tried that (no dice). He also
suggested trying turning off nat in the cisco 678 and trying that. Well,
getting the Linksys out of the equation didn't help at all.

I haved tried turning nat off on the cisco, and I planned on letting the
linksys do the nat'ing. But I'm unable to figure out how to even get the
networking to work in this configuration. Does anyone else do anything like
this with their Linksys? Also, after I set this and rebooted, I could no
longer telnet to the Cisco since I guess it no longer has an IP? I had to
use the direct cable from Win98 Hyperterminal.

The admin has offered to help me this weekend, but before I go and bug him
on his labor day weekend, I thought I'd try the cisco w/ no nat and linksys
doing the nat ( I did find a page that suggests some settings for the
linksys to allow vpn to work). Any suggestions welcome.


 
> ----- Original Message -----
> From: <black at galaxy.silvren.com>
> To: <clue-tech at clue.denver.co.us>
> Sent: Tuesday, August 12, 2003 08:04
> Subject: Re: [CLUE-Tech] Marginally OT: VPN client
> 
> 
> > Something else to keep in mind: Even though you're using SNAT, the private
> > addresses you choose on your end ARE significant! The local IP addresses
> > gets wrapped into the data portion of the packet... the "public" IP
> > addresses are only used to route your IPSEC traffic between your SNAT
> > device and the VPN gateway.
> >
> > In other words, if you're using 10.0.0.0/24 at home and somewhere on the
> > corporate side they're using 10.0.0.0/24, you're gonna have a routing
> > issue and packets will never make it back to you.
> >
> > You might want to ask your VPN admin if this is the case.
> >
> >
> > On Mon, 11 Aug 2003, David Anselmi wrote:
> >
> > > Sean LeBlanc wrote:
> > > [...]
> > > > That option about IPSec over UDP is the default, and I was told to use
> that.
> > > > A co-worker has cable, and he had the following in iptables:
> > > >
> > > >    -A INPUT -i eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT
> > > >    -A OUTPUT -o eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT
> > > >    -A INPUT -i eth0 -p 50 -j ACCEPT
> > > >    -A OUTPUT -o eth0 -p 50 -j ACCEPT
> > >
> > > This is appropriate for firewall rules on the client.  If the firewall
> > > was between the client and server you would use the FORWARD chain rather
> > > than INPUT and OUTPUT.
> > >
> > > > For grins, I did what I thought would be the Cisco 678 translation:
> > > >
> > > > set nat entry add 10.0.0.2 500
> > > > set nat entry add 10.0.0.2 0 50
> > >
> > > No, the 678 equivalent to INPUT and OUTPUT is "set fi" -- the packet
> > > filters.  "set nat" is the equivalent of "iptables -t nat -A
> > > PREROUTING".  Your entries allow the Internet to connect to your
> > > 10.0.0.2 box (assuming no filtering).
> > >
> > > For your client you don't need this -- the SNAT the 678 does for you is
> > > automatic (if you have nat enabled).
> > >
> > > Try running ethereal on your client.  I bet that what you'll see is 3 or
> > > 4 ISAKMP packets go out (UDP port 500 on both ends).  But nothing will
> > > come back.  So either something is blocking the packets before they get
> > > to the server or it's blocking the packets coming back to you.
> > >
> > > I'm guessing you don't have access to both ends of this connection (you
> > > could use netcat or something to test with then).  Have you talked to
> > > the VPN admin?  The two times I've done this (different admins) it was
> > > their end in both cases.
> > >
> > > Good luck!
> > > Dave

-- 
Sean LeBlanc:seanleblanc at americanisp.net  
http://users.americanisp.net/~seanleblanc/
Get MLAC at: http://sourceforge.net/projects/mlac/
There is nothing wrong with Southern California that a rise in the ocean level 
wouldn't cure. 
-Ross MacDonald