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.
--linas
----- Forwarded message from linas -----
To: [email protected], [email protected]
Subject: NFS on a freeswan gateway?
Hi,
I'd like to run an nfs client on a freeswan gateway. As the mailing
list archives attest, others on the mailing list have found that this
doesn't always work. I think I know why, and am about to trying
patching to fix the problem, but ... before I get too deep, I was
wondering if anyone already knows of a patch that fixes this?
Problem:
Can't mount nfs volumes on a freeswan gateway. Message on the gateway:
mount: xxx failed, reason given by server: Permission denied
Message at the server:
Jun 24 14:56:00 rpc.mountd: refused mount request from nn.nn.nn.nn for /xxx (/): no export entry
Analysis:
The server refuses the client because the IP address nn.nn.nn.nn is 'wrong'.
The nfs server will only export to 'internal' addresses (e.g. 10.x.y.z)
whereas the mount client used an external nn.nn.nn.nn address.
I tried switching eth0 <--> eth1, etc. but is seems that the mount client
keeps trying to use a source address that corresponds to the default gateway
(which is *not* ipsec0).
Solution:
Search the web. No luck. Try to patch the linux kernel. I am going to
crawl through the linux kernel rpc code to see if I can make it use a
source address that is routing-wise 'closer' to the target address.
But I was wondiering if anyone already had some work-around for this ...
--linas
p.s. No, I do *not* want to make ipsec0 the default gateway for all
my traffic, so that 'workaround' is not an option.
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[email protected]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
----- End forwarded message -----
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[email protected]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
>>>>> " " == Linas Vepstas <[email protected]> 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
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Linas,
This looks to me to be a configuration issue. RPC always and has always
presented it's default route interface IP when connecting. If you are
attempting to mount to an NFS server on a network that is reachable from the
inside interface, you would need to add the default interface IP to your
/etc/exports file. If you are trying to go across the IPSec tunnel to attach
to an NFS server on the other side, you need to add a second connection in the
ipsec.conf file for the ipsec computer it self...
Maybe I'm missing something, but tests show that this will work as advertised...
Stu
Trond Myklebust wrote:
>>>>>>" " == Linas Vepstas <[email protected]> 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
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 <[email protected]> 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!) <[email protected]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
> >>>>> " " == Linas Vepstas <[email protected]> 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!) <[email protected]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
On Mon, Jun 24, 2002 at 05:06:15PM -0700, Stuart Sheldon was heard to remark:
> Linas,
>
> This looks to me to be a configuration issue. RPC always and has always
> presented it's default route interface IP when connecting.
As per other note, it seems that other things (e.g. telnet) 'present
the default route interface IP' when connecting. News to me ...
> If you are
> attempting to mount to an NFS server on a network that is reachable from
> the inside interface, you would need to add the default interface IP to
> your /etc/exports file.
:-( well, of course, that interface is some dynamcially assigned address
that some ISP provided. Hardly a thing I'd want to put in /etc/exports.
Now, I could wire up the internal DNS so that it learns about the
IP address that the ISP assigned. That way, I could put the name of
the machine, instead of a dotted numeric address, in the /etc/exports file.
But this adds more complexity, and I'm somewhat concerned about the security
implications (dns spoofing & etc.).
I would be much happier if mount (and telnet & ping &etc). used a source
address that corresponded to the interface from which the packets came.
That way, I could set up my packet filters to roundly reject all traffic
from external interfaces (other than the secure ipsec traffic).
----
The basic idea is to allow roaming clients to get nfs access to internal
networks. The roaming client has a built in firewall to block almost
everything, and a freeswan tunnel to get it onto the internal net.
Having the source address be the default route IP addr rather than
the internal addr just gums it all up.
I think this is a question for the networking gurus.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[email protected]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
After a recent upgrade from solaris 2.6 to 2.8, my linux nfs client can no
longer nfs mount to the sun machine. I can mount to two other 2.8 boxes
w/out problems(they were installed fresh as 2.8 and since only patched up).
I get permission denied, however dmesg reveals:
call_verify: server requires stronger authentication
While googling I came across many references to linux nfs not being capable
of kerberos authentication, but haven't found a resolution or work around.
I hope this is the appropriate forum. In trolling here for the past week it
seems to be.
Can anyone give me more insight or progress of a fix? Thank you very much
in advance for your attention.
Dan
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
I have a Solaris 8 NFS server mounting to 25 Redhat 7.1 clients. I had much
trouble with the same type of thing, the mount was fine as long as the user
was root, but as soon as a non-root user logged on, the data disappeared
even the mount still persisted. My log did have the same message. After
much tinkering, I at one point added "log,nosuid" to my /etc/dfs/dfstab
options and the mounts on the Linux machines now are good. I am not sure if
it was this exact thing that helped, but it's addition seemed to coincide
with the time the mounts became persistent. Good Luck!
Patrick
_______________________________________
Patrick O'Reilly
Meteorological Decision Support Scientist
The STORM Project - University of Northern Iowa
[email protected] ~ ph: 319-273-3789
----- Original Message -----
From: "webmaster" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, June 25, 2002 3:30 PM
Subject: [NFS] Linux -> Sun NFS doesn't mount
> After a recent upgrade from solaris 2.6 to 2.8, my linux nfs client can no
> longer nfs mount to the sun machine. I can mount to two other 2.8 boxes
> w/out problems(they were installed fresh as 2.8 and since only patched
up).
> I get permission denied, however dmesg reveals:
>
> call_verify: server requires stronger authentication
>
> While googling I came across many references to linux nfs not being
capable
> of kerberos authentication, but haven't found a resolution or work around.
> I hope this is the appropriate forum. In trolling here for the past week
it
> seems to be.
>
> Can anyone give me more insight or progress of a fix? Thank you very much
> in advance for your attention.
>
> Dan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber Inc.
> Don't miss the IM event of the season | Special offer for OSDN members!
> JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Jun 24, 2002 at 07:23:17PM -0500, Linas Vepstas wrote:
>
> 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
I have played with FreeS/WAN and saw that an ipsec interface would always
get the same address as the eth interface (i.e. on the internet) emitting
the corresponding ESP packet. Routing happens in a nonobvious way.
This addressing scheme is fundamentally broken (the FreeS/WAN people
know it) and may be the cause of the problem.
There is some other weirdness with FreeS/WAN: when you connect
two networks each having a FreeS/WAN gateway machine then any packet
generated on the gateway machine itself cannot be tunnelled: the packets
are dropped by the FreeS/WAN address checking code (source address problem
as far as I remember). Sounds like the problem you are experiencing.
--
Frank
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs