[strongSwan] nfs across strongswan
noel at familie-kuntze.de
Wed Sep 24 14:30:19 CEST 2014
-----BEGIN PGP SIGNED MESSAGE-----
Please keep it on the list.
Not using NAT is the correct way to go, as long as you don't start leaking
your RFC1918 network into publiclcy routable address space.
Please read  for some explanations, if you don't already understand the need for NAT.
The pool used by strongSwan for the virtual IPs is either in RAM or in SQL, so it's
static for each road warrior.
An example for SQL based pool backends can be found here 
 is the SQL scheme with the virtual IP pool section
Mit freundlichen Grüßen/Regards,
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Am 24.09.2014 um 12:58 schrieb Cindy Moore:
> Right, the uids have to match (I know much more about nfs than I do
> vpn, fortunately -- not worried there). I'm not at all intending to
> automount, the roadwarriors can mount directories themselves once
> they're connected.
> So if I exempt traffic between roadwarriors and the nfs-server by
> earlier accepts in the iptables, the roadwarriors will present
> themselves with the correct virtual ip address? I don't understand -
> I would actually love for the road warriors to always present as their
> virtual ip and never as the vpn server's ip, so this almost sounds
> like I should just clear out iptables rules altogether. That can't be
> right? Or is it more like, I should avoid natting if the traffic is
> entirely within the private vlan and only nat when the connected
> roadwarrior goes outside the private vlan?
> I'm a little less clear on why I need the database (sqlite or mysql,
> which ever) for persistent virtual ip's, though? I have a range of
> ip's reserved for the vpn in our named file (including reverse lookup
> definition) and have planned to set up individual roadwarrior
> connections for each certificate, with an ip listed in rightsourceip
> for that conn. That won't work? Somethign like
> conn rw-<username>
> rightid="C=CH, O=strongSwan, CN=<username>@example.com"
> (and then in the exports file, an entry for /project/<username> to be
> exported to 184.108.40.206 Once <username> is connected, they can worry
> about mounting it )
> No, it would not scale up very nicely, but our department is not that
> large. Does the sql backend let me define one conn as framework and
> then list all the user/virtual ip pairings?
> Oh, also, I tried to look for the example (you said "You do this by
> using an SQL backend. See  for an example.") but I didn't see a
> Thank you so much,
> On Wed, Sep 24, 2014 at 12:25 AM, Noel Kuntze <noel at familie-kuntze.de> wrote:
> Hello Cindy,
> First of all: You can excempt some traffic from nating, if you ACCEPT
> it before the nat rule.
> e.g. POSTROUTING *nat:
> -t nat -A POSTROUTING -s myVirtualIPNetwork/24 -d myNFSServer -m policy --pol ipsec --dir in -j ACCEPT
> -t nat -A POSTROUTING -s myVirtualIPNetwork/24 -m policy --pol ipsec --dir in -j MASQUERADE
> Do NOT, I REPEAT, DO NOT mount or unmount the nfs share with the updown script!
> The problem is that ...
> a) You can't successfully unmount the share with the updown script,
> because the corresponding hook is called _after_ the tunnel was torn down.
> b) You can get problems with accessability of the nfs share, if
> UID and GID of the local user and the owner of the file mismatch!
> You need to force the remote file owner to be mapped to the local user
> by using the corresponding flags in the mount definition either on mount
> time or in /etc/fstab.
> You can set up different shares for different roadwarriors by assigning different IPs to them,
> but assigning the same one for the same roadwarrior identity. For this, you need a persistent
> virtual IP pool. You do this by using an SQL backend. See  for an example.
> Setting up an export for those virtual IPs should be quite easy.
> You might need to do some custom scripting though to retrieve the virtual IP
> that corresponds to the different users and modifying /etc/exports correctly.
> As the pool is stored in an SQL database, you might want to use mysql as backend,
> as it performs better than using sqlite and has a command line utility to perform
> Mit freundlichen Grüßen/Regards,
> Noel Kuntze
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
> Am 24.09.2014 um 07:06 schrieb Cindy Moore:
>>>> Has anyone managed this?
>>>> Set up an export to a virtual ip.
>>>> Set up a strongswan conn to assign that virtual ip to a specific roadwarrior.
>>>> Have that roadwarrior successfully nfs mount the directory once
>>>> connected to the vpn.
>>>> I find no examples resembling this. I'm stumped in this process
>>>> because all the roadwarriors, even though assigned virtual ip's
>>>> correctly according to their tun0 settings, are presenting themselves
>>>> as having the ip address of the vpn server, which I assume is because
>>>> it's natting everything. I'm at a loss as to how to get around this,
>>>> so if someone has done this, I would LOVE to see your conf files and
>>>> your iptable setup, please, please?
>>>> Users mailing list
>>>> Users at lists.strongswan.org
>> Users mailing list
>> Users at lists.strongswan.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the Users