Hi,
I think I made some progress on my freeswan/nfs-mount problem;
see below.
To summarize, it appears that freeswan and/or the linux kernel is
issueing packets from the ipsec0 interface that do not carry the
ipsec0-device default source address, but rather carry the source
address of eth0/eth1. And that seems wrong to me: if a gateway
machine creates a packet and puts it on the internal net, it should
be using the source address that is appropriate for the internal net:
i.e. it should be using the source address of the interface from
which the packet issued.
This seems to me to be a freeswan bug, and/or a kernel 'feature'.
Comments?
--linas
On Tue, Jun 25, 2002 at 01:13:36AM +0200, Trond Myklebust was heard to remark:
> >>>>> " " == Linas Vepstas <linas_at_linas.org> writes:
>
> > Hi, I am resending a message sent to the freeswan mailing list.
> > As explained below, the default IP source address used in nfs
> > mount requests is sometimes 'not appropriate' for certain
> > packet-filtering/freeswan setups.
>
> > I'd like to patch that part of the nfs/rpc client so that it
> > uses an IP source address that is routing-wise 'closer' to the
> > nfs server. But I have damned little experience with the nfs
> > kernel code (or nfs internals), and thus would like an opinion,
> > or commnts, or, best yet, a pointer to a pre-existing patch.
>
> Both the client and the server use the standard IP socket layer
> code. There is no magic... IOW if ordinary sendmsg()/recvmsg() of UDP
> packets over the ipsec0 interface works (and the resulting address in
> the struct msghdr is correct) then NFS should work fine.
Yes, right. Maybe I spoke too soon, or put on the wrong empahsis.
When I ran 'strace mount', I found normal/generic UDP behaviour:
bind(3, {sin_family=AF_INET, sin_port=htons(641), sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
mount is binding a source address of all zeros, which the kernel fills
in; this is normal udp programming; so no problem yet.
The problem is, of course, tha the kernel fills in a source address
that corresponds to the device that the default gateway is on, which
is the box's external address. I am not sure how or why the kernel
does this (other than that it seems to happen in ip_route_output()
in route.c, which calls inet_select_addr(), etc.)
> If, however, you are trying to use NAT or masquerading or something
> like that on the FreeSWAM gateways in order to translate 'internal
> addresses' into 'external addresses', then you are screwed: NAT is not
> an appropriate protocol for UDP services.
Well, yes, and no. NAT is a red herring, because (1) the problem
occurs when there's no NAT on the box (2) if there was NAT on the box,
I'd still want/expect these particular packets to not be NAT'ed.
----------------
On further analysis, I see now that *all* packets (tcp, icmp) and
not just the udp (rpc/nfs) packets get the 'external' address as the
source address. That is, for example,
if I try to telnet to an internal address, on the far side of a freeswan
tunnel, from the freeswan gateway, the packets get there and back just
fine (which means the gateway is working), but thier 'source' addresses
are the external-network adddress, rather than the expected/hoped-for
internal-network address.
Thus, my problem: my nfs exports only allow internal IP addrs, but the
freeswan code is putting packets with 'external' source addresses on
the internal network. I conclude: this is not an NFS problem,
this is a generic packet-routing problem.
I'm now thinnking that maybe this is a freeswan bug. If its not
a freeswan bug, then its a kernel 'feature'. At any rate, packets
that left the 'ipsec0' interface had the source address of the eth1
interface, which seems wrong to me ....
>
> Cheers,
> Trond
-- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas_at_linas.org> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 > >>>>> " " == Linas Vepstas <linas_at_linas.org> writes: > > > Hi, I am resending a message sent to the freeswan mailing list. > > As explained below, the default IP source address used in nfs > > mount requests is sometimes 'not appropriate' for certain > > packet-filtering/freeswan setups. > > > I'd like to patch that part of the nfs/rpc client so that it > > uses an IP source address that is routing-wise 'closer' to the > > nfs server. But I have damned little experience with the nfs > > kernel code (or nfs internals), and thus would like an opinion, > > or commnts, or, best yet, a pointer to a pre-existing patch. > > Both the client and the server use the standard IP socket layer > code. There is no magic... IOW if ordinary sendmsg()/recvmsg() of UDP > packets over the ipsec0 interface works (and the resulting address in > the struct msghdr is correct) then NFS should work fine. > > If, however, you are trying to use NAT or masquerading or something > like that on the FreeSWAM gateways in order to translate 'internal > addresses' into 'external addresses', then you are screwed: NAT is not > an appropriate protocol for UDP services. > > Cheers, > Trond-- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas_at_linas.org> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:16 CEST