On Jun 2, 2018, at 9:45 AM, J Vans <[email protected]> wrote:
>> > On Jun 2, 2018, at 6:03 AM, Stuart Henderson <[email protected]> wrote:
>> > > > On 2018-06-01, J Vans <[email protected]> wrote:
>> > > I am trying to route all of my ipv4 traffic through a particular server
>> > > > > using OpenIKED. I have it successfully set up so that each client
>> > > can > > connect, and the traffic passes through correctly, but it only
>> > > works for > > one client at a time. If Client A is connected by itself
>> > > things work > > just fine, but once I connect Client B, Client B works
>> > > and client A no > > longer is able to pass any traffic out. I restart
>> > > IKED on Client A, and > > Client B loses it's connection.
>> > > > > I searched through misc and didn't find anyone talking about exactly
>> > > > > > > what I was trying to do, and a web search turned up one useful
>> > > > > result > > that claims using ikev2 I cannot do this without ipv6. >
>> > > > > >
>> > > > > https://serverfault.com/questions/775238/two-road-warrior-clients-behind-the-same-nat-device-ikev2-strongswan-libreswa
>> > > The claim that nat can't differentiate between the traffic of each > >
>> > > client makes sense to me, but there is a lot I do not know.
>> > > The claim in that reply about needing IPv6 and NAT not working is
>> > nonsense, the port numbers are different. This is exactly what NAT-T
>> > fixes.
>> > > > I know that traffic can be tagged by IKED and have tried routing by
>> > > > tag > > in pf to no avail. However, it is possible I have not done
>> > > > this correctly.
>> > > > > My questions are:
>> > > > > 1. If I want multiple "road warrior" clients behind nat in IKED do I
>> > > > > > > need to implement ipv6?
>> > > > > 2. Is there a different way to accomplish this besides ipv6?
>> > > > > > > > > I don't have a setup handy to test at the moment but I don't
>> > > > > > > > > think > there's anything special to do here. If you show
>> > > > > > > > > your config (iked,
>> > pf, outline of network setup) maybe somebody will notice something?
>> >
>
> Thank you, I was after a "possible" or "not possible", and it sounds like what
> I want to do is possible. Below are my the test configs.
>
>> I had a similar problem when trying to assign specific IP addresses based on
>> asn1 id.
>
> I have this problem assigned ip addresses or no.
>
>
> CONFIGS
>
> 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 ---/
>
> I am posting a less complicated setup, it is the configs from
> http://puffysecurity.com/wiki/openikedoffshore.html
>
> This setup works fine, but only for one client at a time. I can ping out on
> one client, and as soon as I start iked on the other, the pinging stops.
>
> In my more complicated setup I am using unbound for DNS and assigning static
> ip
> addresses to each peer, but I am having this problem both ways so maybe start
> simple and work from there.
>
>
> SERVER CONFIGS
>
> iked.conf
>
> ikev2 passive ipcomp esp \
> 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
>
>
> pf.conf
>
> set reassemble yes
> set block-policy return
> set loginterface egress
> set skip on { lo, enc }
>
> match in all scrub (no-df random-id max-mss 1440)
>
> table <bruteforce> persist
>
> block in log
> block in quick from urpf-failed label uRPF
> block quick from <bruteforce>
>
> pass out all modulate state
>
> pass in on egress proto udp from any to any port { isakmp, ipsec-nat-t }
> pass in on egress proto { ah, esp }
> 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)
>
> 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)
>
>
> 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
>
>
> pf.conf
>
> set reassemble yes
> set block-policy return
> set loginterface egress
> set skip on { lo, enc }
>
> match in all scrub (no-df random-id max-mss 1440)
>
> table <bruteforce> persist
>
> block in log
> block in quick from urpf-failed label uRPF
> block quick from <bruteforce>
>
> pass out all modulate state
>
> 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)
>
>
> sysctl.conf
>
> net.inet.ip.forwarding=1
> net.inet.ipcomp.enable=1
>
On the server Iked.conf try adding
config address x.x.x.x/24 \
config netmask 255.255.255.0
Or whatever address space you like. This address space should be a virtual pool
that’s only used for the vpn. At least that’s the only way I’ve used it.
