Bug [EMAIL PROTECTED] and make him write up a little nerdy whitepaper
on using ipsec with authpf and NAT for trackable roaming VPN clients.
That's what we use here.
Very distilled summary is that the clients connect with a fairly
vanilla vpn setup, but then must authpf authenticate before traffic
will be routed for them throught he tunnel. the authpf setup is then
very simliar to the one in the authpf(8) man page in the section
"DEALING WITH NAT".
Yes, using ssh to authenticate instead of ipsec sucks, but that's
because all authentication mechanisms used by ipsec are stinking crap
not fit to deploy to actual real life mouth-breathing-knuckle-dragging
lusers that expose their machines constantly.
-Bob
* Jean-Christophe Sicard <[EMAIL PROTECTED]> [2005-05-11 23:50]:
> Hi all,
>
> The situation is as follows:
> I've setup isakmp for roaming clients vpn access with only shared secret
> authentication.
> Roaming users use the windows ipsec client to connect, which works
> fine.(albeit with some manual intervention when local ip changes but
> still it works.)
> Now the thing is it use to be that I was the only one connecting through
> the vpn, but I've now started giving access to some others too.
>
> The issue at hand is two fold: I...
> a) Would like some more granular (ie: user level) authentication, access
> control and accountability, somewhat like PIXes do with nasty x-auth.
> b) Would like to have users access the internal network with a specific
> pool of IPs, preferably in a per user IP assignemt system, (whereafaik
> virtual IPs aren't supported by isakmp.)
>
> Now I know that using x509 certs auth could potentially solve both
> issues, both I would prefer using an authpf solution...
> The senario would be like this:
> User establishes the vpn tunnel with shared secret auth.
> All traffic is blocked with pf on from enc0.
> User ssh into authpf shell to load appropriate pass rules on enc0 for
> the client as well as a binat rule for the client's local "vpn" ip...
>
> Now I don't forsee any problem with the access filtering part (issue
> "a)") of the authpf setup.
>
> For issue "b)" however, from my tests on 3.6 stable, it doesn't seem
> possible to binat my incoming traffic from the vpn clients on enc0. And
> the reason (I think!) I want to binat on enc0 rather than my IntIF is
> that I need to distinguish incoming traffic from the VPN and possible
> non encrypted (via InternetIF for example) connections from the same IP
> (tunnel endpoint) which should not be binated.
>
> So I guess my questions are:
> - Can I binat incoming decrypted vpn traffic on enc0?
> - If not, should a workaround like "pass in on enc0 tag vpn_traffic"
> with a "binat on $IntIF from $user_ip to any tagged vpn_traffic ->
> 192.168.10.X" work on 3.7 (as binat tagged isn't supported in 3.6)?
> - Am I thinking too much and binating directly on $IntIF from $user_ip
> without tagging would be perfectly safe of accidental collisions?
> - Any other clues?
>
>
> JC
>
--
Bob Beck Computing and Network Services
[EMAIL PROTECTED] University of Alberta
True Evil hides its real intentions in its street address.
