Re: 3.5: stupid VPN problem

[<nickf3_(_at_)_mail_(_dot_)_ru>]

Hi there,
I have ~same setup for my vpns (all subnet-2-subnet, 3.4 so far):

The master:

Encap:
Source             Port  Destination        Port  Proto SA(Address/Proto/Type/Direction)
192.168.3/24       0     10.1/16            0     0     cl.ie.nt.16/50/use/in
10.1/16            0     192.168.3/24       0     0     cl.ie.nt.16/50/require/out
...

And one of the clients:

Encap:
Source             Port  Destination        Port  Proto SA(Address/Proto/Type/Direction)
10.1/16            0     192.168.3/24       0     0     ma.st.er.81/50/use/in
192.168.3/24       0     10.1/16            0     0     ma.st.er.81/50/require/out

Here is what I do when I need traffic (not just ping, do that
with -I) between client gw and the master gw:

/etc/rc.local:
    /sbin/route add -net 10.1 192.168.3.1
/etc/sysctl.conf:
    net.inet.ip.redirect=0 # shut down ICMP host redirects

The "ICMP host redirect" is sent when a packet entering
a gateway through an interface is routed back to the same
interface (theory again :), which is effectively what happens here.

On Thu, 6 May 2004, Toni Mueller wrote:

> Hi,
>
> On Wed, 05.05.2004 at 22:52:04 -0600, jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org> wrote:
> > $ netstat -rnf encap
> > Routing tables
> >
> > Encap:
> > Source             Port  Destination        Port  Proto SA(Address/Proto/Type/Direction)
> > 192.168.23.129/32  0     192.168.7.0/27     0     0     206.168.0.33/50/use/in
> > 192.168.7.0/27     0     192.168.23.129/32  0     0     206.168.0.33/50/require/out
>
> so, in your case, 206.168.0.33 is the other side, and you have
> tunneling with ESP, too.
>
> >   i typically include an /etc/hostname.fxp1 routing entry of:
> > !/sbin/route add -net 192.168.23.128/25 -interface 192.168.7.17 > /dev/null 2>&1
>
> For my other (pre-3.5) VPNs, I have no such route. Selecting the VPN
> for routing has been automatic so far (for me at least).

I'm sorta wondering why is that. You do have default gateway/
default route via external interface, the inet routing table
doesn't say anything about the other subnet. So when packet
is sent from the gateway to the other subnet, the decision
is simple - shove it along the default route. At this point
the packet gets the source IP of external int and flies into the wild.
So it must be the order OS recognizes your NICs - with two interfaces,
say fxp0 attached to the local net and fxp1 to external net,
the default route would be via fxp0, so packet goes there,
matches encap route and happily flies into the tunnel.
But how would you route non-vpn traffic to the outside then? ?-)

Toni, to your original post, I noticed that you don't have
default routes there. I think this is the problem. Set them
to fxp1 on both sides and you should be in business.

Cheers,
--
 nickf3

>
> >   is it *needed* to manually add a route for traffic originating on the router
> >   to be able to talk to 192.168.23.129, and if yes, can it be done without
>
> Hmm... My take on routing so far is this:
>
> A packet originating on some machine usually gets a sender IP address
> from the interface it uses to leave the machine. For your typical
> two-legged VPN gateway, this would be the address on the outside if you
> want to reach something on the other side, but this address isn't
> usually part of the networks tunneled over the VPN. If it's reasonable
> to add two (four?) additional flows to be able to directly ping the
> other side, I don't know. Using source selector mechanisms like in
> ping -I, is sufficient for me.
>
> [ pure speculation ahead - can anyone please confirm? ]
>
> So, for a "new" packet originating on the first comes the routing
> decision, then the appropriate source address is selected for that
> packet (it looks as if it is done that way). For packets belonging to
> some other data stream, like an ongoing ssh session, it looks like the
> packet from the host usually (always?) uses as the source address the
> destination address of the last incoming packet for that data stream.
> (Apart from observing this behaviour, not doing it this way would at
> least break TCP since there would often be no reply from the target,
> but from some other address on that host in case of IP aliasing or
> multihomed machines).
>
> >   or would be this something where i would run routed, or should it be Just
> >   Working and i must be messing something else up?
>
> I strongly oppose running routed for most cases, regardless whether you
> have a VPN or not. In the situation you described, I really think it
> would make things worse. In any case if you only have two /24 to route,
> manual routing should be better unless you have very special
> requirements, and then you are still better off looking into
> OSPF-something, like quagga.
>
>
> Best,
> --Toni++