[strongSwan] nfs across strongswan
Noel Kuntze
noel at familie-kuntze.de
Wed Sep 24 14:30:19 CEST 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Cindy,
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 [1] 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 [2]
[3] is the SQL scheme with the virtual IP pool section
[1] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
[2] http://www.strongswan.org/uml/testresults/ikev2/ip-pool-db/
[3] https://wiki.strongswan.org/projects/strongswan/repository/entry/src/pool/mysql.sql#L209
Mit freundlichen Grüßen/Regards,
Noel Kuntze
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>
> keyexchange=ikev2
> leftauth=pubkey
> right=%any
> rightid="C=CH, O=strongSwan, CN=<username>@example.com"
> rightauth=pubkey
> #rightauth2=xauth-pam
> rightsourceip=1.2.3.102
> auto=add
>
> (and then in the exports file, an entry for /project/<username> to be
> exported to 1.2.3.102 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 [1] for an example.") but I didn't see a
> link?
>
> Thank you so much,
> --Cindy
>
> 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 [1] 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
> queries.
>
> 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?
>>>>
>>>> Thanks
>>>> Cindy
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.strongswan.org
>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>>
>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUIrlaAAoJEDg5KY9j7GZYr5gP/1/lDioWgKJzDvNKiBogUyhU
8F232KtVooxUoAjLk0idXMBdJokujyyrRRfsrYiYSIzL+DYhpQCyeZyxjxLjCOfl
/FAlT/4jxlGrdXdxzA4sFXrqve5A4I28Fd4UYmSnXuZnMCWlJobUA3dAxbrtO2tX
H2OPgAaguJA3x0EezTnpAnqtmq5C4Ul4lFiAaQnaqyU6lQQ+uLKqFbU4Di8xvI+i
3RWSYxGsVJL75i39QsEpRdr/Praq2ksJDIvB7E+teTAsR7U8rysWWiUtrOxWiCdf
hL4iO0ltYqQDYp+9beH6fUvhgd0dhw+AKH+Y0ijodCJQkNWSsdZYxcV55+sejGSb
WCHyhN2ntUz4jNiTcqNiLheIhmXjcB91kNb1LyIB6PmP2414LgBaodpwfy0/5ea5
KpwV88uUmtiYfd9bR0HQDPiqw8iI5EWlV1hZEt3klVYryr7wf80J5pUYQECwPG7m
9uejMGLOxdsZGwOexk7ArhWAglOxhL2HBrGzTRvADd2y1pDZk43wWhgEJGNOZL+R
4+jIo7IKM+FrMxKKuDaw38ekyOJycdTDior5UyavAi6hECFKI5SyFioi/WlugI/j
EaVs8W05EjSq6qKC1VIheINz5IExBfOuvDNavK8sM6uzsSkez03RSqqQTdvDQPdO
3UviZekIC9k2I/H/kvVF
=fQDL
-----END PGP SIGNATURE-----
More information about the Users
mailing list