ipsec tunnel and vnet jails: routing, howto?
Michael Grimm
trashcan at ellael.org
Sun Dec 27 18:14:59 UTC 2015
Julian Elischer <julian at freebsd.org> wrote:
>
> On 27/12/2015 4:24 AM, Michael Grimm wrote:
>> I am currently stuck, somehow, and I do need your input. Thus, let me explain, what I do want to achieve:
>>
>> I do have two servers connected via an ipsec/tunnel ...
>> [A] dead:beef:1234:abcd::1 <—> dead:feed:abcd:1234::1 [B]
>> … which is sending all traffic destined for dead:beef:1234:abcd::/64 and dead:feed:abcd:1234::/64 through the tunnel, and vice versa.
>>
>> That did run perfectly well during the last years until I decided to give VNET jails a try. Previously, some of my old fashioned jails got an IPv6 address attached like dead:beef:1234:abcd:1:2::3, and I could reach that address from the remote server without any routing/re-directing or alike, necessary. Now, after having moved those jails to VNET jails (having those addresses bound to their epairXXb interfaces), I cannot reach those addresses within those jails any longer.
>>
>> >From my point of view and understanding this must have to do with lack of proper routing, but I am not sure, if that is correct, thus my questions to the experts:
>>
>> 1) Is my assumption correct, that my tunnel is "ending" after having passed my firewalls at each server, *bevor* decrypting its ESP traffic into its final destination (yes, I do have pf rules to allow for esp traffic to pass my outer internet facing interface)?
>>
>> 2) If that is true, racoon has to decide where to deliver those packets, finally?
>>
>> 3) If that is true, I do have an issue with routing that *cannot* be solved by pf firewall rules, right?
>>
>> 4) If that is true, what do I have to look for? What am I missing? How can I route incoming and finally decrypted traffic to its final destination within a VNET jail?
>>
>> 5) Do I need to look for a completely different approach? Every hint is highly welcome.
>
> basically you have to treat the jails as if they are totally separate machines that are reached through the vpn endpoints instead of being the endpoints themselves.
> This will require a different setup. for example your tunnel will need to be exactly that a tunnel and not just an encapsulation. And you will need full routing information for the other end at each end.
Thanks for your input. In the meantime I got it running, somehow. The "somehow" refers to: I am not sure if that's the way its supposed to be.
What I did (I do only show the part of host [A], the other host is configured accordingly):
1. ipsec/tunnel between [A] dead:beef:1234:abcd::1 <—> dead:feed:abcd:1234::1 [B]
/path-to-racoon/setkey.conf:
spdadd dead:beef:1234:abcd::/56 dead:feed:abcd:1234:1:2::3 any -P out ipsec esp/tunnel/dead:beef:1234:abcd::1-dead:feed:abcd:1234::1/require;
spdadd dead:feed:abcd:1234::/56 dead:beef:1234:abcd:1:2::3 any -P in ipsec esp/tunnel/dead:feed:abcd:1234::1-dead:beef:1234:abcd::1/require;
2. routing at [A]:
/etc/rc.conf:
ipv6_static_routes="jail1"
# that's for the route from host system [A] into jail1 with IPv6 address of fd00:ffff:ffff:ffff:aaaa::1
—> ipv6_route_mail="-host dead:beef:1234:abcd:1:2::3 -host fd00:ffff:ffff:ffff:aaaa::1"
/etc/jail.conf:
#
# host dependent global settings
#
$ip6prefix = "dead:beef:1234:abcd";
$ip6prefix_remote_host = "dead:feed:abcd:1234";
#
# global jail settings
#
host.hostname = "${name}";
path = "/usr/home/jails/${name}";
mount.fstab = "/etc/fstab.${name}";
exec.consolelog = "/var/log/jail_${name}_console.log";
vnet = "new";
vnet.interface = "epair${jailID}b";
exec.clean;
mount.devfs;
persist;
#
# network settings to apply/destroy during start/stop of every jail
#
exec.prestart = "sleep 2";
exec.prestart += "ifconfig epair${jailID} create up";
exec.prestart += "ifconfig bridge0 addm epair${jailID}a";
exec.start = "/sbin/ifconfig lo0 127.0.0.1 up";
exec.start += "/sbin/ifconfig epair${jailID}b inet ${ip4_addr}";
exec.start += "/sbin/ifconfig epair${jailID}b inet6 ${ip6_addr}";
exec.start += "/sbin/route add default -gateway 10.x.x.254";
exec.start += "/sbin/route add -inet6 default -gateway fd00:ffff:ffff:ffff:aaaa::254";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.poststop = "ifconfig epair${jailID}a destroy";
#
# individual jail settings
#
mail {
$jailID = 1;
$ip4_addr = 10.x.x.1;
$ip6_addr = fd00:ffff:ffff:ffff:aaaa::1/64;
exec.start += "/sbin/ifconfig epair${jailID}b inet6 ${ip6prefix}:1:2::3/56 alias";
—> # that's for the route to remote host dead:feed:abcd:1234:1:2::3 at tunnel end point [B] out of jail1
exec.start += "/sbin/route add -6 ${ip6prefix_remote_host}:1:2::3 fd00:ffff:ffff:ffff:aaaa::254";
exec.start += "/bin/sh /etc/rc";
}
That is working well, after racoon has established the tunnel.
*But* unlikely what I have observed before, the very first contact to the remote server's [B] jail out of a jail at [A] doesn't trigger racoon to establish the tunnel. Before, that happened instantaneously, but now I do need to to some "tricks" with ping6s and/or restarting racoon at the host system. I haven't found out yet what the cause is … I am sure that I need to learn much more regarding routing. Every feedback is highly welcome.
Thanks and regards,
Michael
More information about the freebsd-net
mailing list