On 2018-06-02, J Vans <[email protected]> wrote:
> Basically I have a vpn server on the public internet, and I want to be able to
> be anywhere and route my traffic through that server.
>
> CLIENT A ---\
> >>>>> VPN >>>>> INTERNET
> CLIENT B ---/
So this is purely traffic from the client devices? Your config covers all the
RFC1918 addresses not just the client IP, so one client connects, sets up
flows for (all rfc1918) to 0.0.0.0/0. Then another client connects and tries
to setup the same flows.
> ikev2 passive ipcomp esp \
Maybe simplify things by getting rid of ipcomp until you have it working.
> from 0.0.0.0/0 to 10.0.0.0/8 \
> from 0.0.0.0/0 to 172.16.0.0/12 \
> from 0.0.0.0/0 to 192.168.0.0/16 \
> local $vpn_server_ip peer any \
> srcid $vpn_server_ip \
> tag IKED
Try the server side with just "from 0.0.0.0/0 to 0.0.0.0/0", I'll talk about
client below.
> set skip on { lo, enc }
You probably at least want some PF processing on enc, even if it's only for
the scrub...max-mss rule.
> match in all scrub (no-df random-id max-mss 1440)
If PF was processing enc so this did take effect there, 1440 would be a bit
high. The actual limit depends on overhead which depends on which settings
get negotiated, I normally use 1310 which might be a bit lower than needed
but hasn't given me any problems.
> block in quick from urpf-failed label uRPF
With enc removed from "set skip", check this doesn't trip you up. On
OpenBSD, IPsec is only done via flows not standard route entries, which
might fail the urpf check (which is a route lookup).
> pass out all modulate state
This shouldn't hurt but I'd try without "modulate state".
> pass out on egress \
> from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } \
> to { ! 10.0.0.0/8, ! 172.16.0.0/12, ! 192.168.0.0/16 } \
> nat-to (egress)
This definitely isn't doing what you expect. Paste it into "pfctl -nvf
-" and see how it expands but basically this ends up as "pass out from
{...} to any nat-to ...".
PF can do multiple negations but they need to be wrapped in a table.
> pass in quick inet proto icmp icmp-type { echoreq, unreach }
>
> pass in quick proto tcp from any \
> to (egress) port ssh \
> flags S/SA modulate state \
> (max-src-conn 15, max-src-conn-rate 15/5, overload <bruteforce>
> flush global)
You don't have a "pass in" for your regular traffic, only icmp/ssh.
>
> sysctl.conf
>
> net.inet.ip.forwarding=1
> net.inet.ipcomp.enable=1
>
>
>
> CLIENT CONFIGS (A and B are identical except $client_hostname)
>
> iked.conf
>
> ikev2 active ipcomp esp \
> from 10.0.0.0/8 to 0.0.0.0/0 \
> from 172.16.0.0/12 to 0.0.0.0/0 \
> from 192.168.0.0/16 to 0.0.0.0/0 \
> peer $vpn_server_ip \
> srcid $client_hostname \
> tag IKED
This is where it starts getting complex, iked doesn't have many features
client-side.
For this setup I'd probably put a static address on a dummy interface (vether
or a new loopback interface, just to hold the address) and use that as the
"from" address in config. When the vpn is up with that you should be able
to connect from multiple clients at the same time without them stomping
on each other's flows *but* you need to make sure packets have the right
source address in order to match the addresses in the flow so they can be
sent over the vpn.
You can test with ping -I $srcip, nc -s $srcip, ssh -b $srcip
but for software where you can't set this you'll need some PF nat or route
tricks on the client side that I'm not goimg to be able to figure out
without a test setup.
> pf.conf
Some similar problems as with the server one.
