Re: PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels

[Philip Higgins]

At a guess, route-to is confused by the same ip, but I haven't looked at the 
internals.

Maybe try adding pair interfaces (with different addresses) to each rdomain,
and you can use route-to to select between them.
You already have default route set in each rdomain, so it will find its way 
from there.

eg.

# /etc/hostname.pair1
group pinternal
rdomain 1
inet 10.255.1.1 255.255.255.0
!/sbin/route -T1 add  10.255.1.2

# /etc/hostname.pair11
group pinternal
inet 10.255.1.2 255.255.255.0
patch pair1

# /etc/hostname.pair2
group pinternal
rdomain 2
inet 10.255.2.1 255.255.255.0
!/sbin/route -T2 add  10.255.2.2

# /etc/hostname.pair12
group pinternal
inet 10.255.2.2 255.255.255.0
patch pair2

# /etc/pf.conf
...
pass on pinternal
...
pass in quick on { $if_int } to any route-to { 10.255.1.1, 10.255.2.1 } \
 round-robin set prio (3,6)

Have not tested exactly this, but similar to my current setup.
Might not need the static routes, if the right pf magic is happening.


-Phil

On 28/11/18 8:18 am, Andrew Lemin wrote:


Hi,

So using the information Stuart and Andreas provided, I have been testing
this (load balancing across multiple VPN servers to improve bandwidth).
And I have multiple VPNs working properly within there own rdomains.

* However 'route-to' is not load balancing with rdomains :(

I have not been able to use the more simple solution you highlighted Stuart
(using basic multipath routing), as the tunnel subnets overlap.
So I think this is a potential bug, but I need your wisdom to verify my
working first :)

Re; Load Balancing SSL VPNs using OpenBSD 6.4, with VPN TunX interfaces in
unique rdomains (overlapping tunnel subnets)

Configure sysctl's
# Ensure '/etc/sysctl.conf' contains;
net.inet.ip.forwarding=1# Permit forwarding (routing) of packets
net.inet.ip.multipath=1 # 1=Enable IP multipath routing

# Active sysctl's now without reboot
sysctl net.inet.ip.forwarding=1
sysctl net.inet.ip.multipath=1

Pre-create tunX interfaces (in their respective rdomains)
# Ensure '/etc/hostname.tun1' contains;
up
rdomain 1

# Ensure '/etc/hostname.tun2' contains;
up
rdomain 2

# Bring up the new tunX interfaces
sh /etc/netstart

fw1# ifconfig
tun1

tun1: flags=8011 rdomain 1 mtu 1500
 index 8 priority 0 llprio 3
 groups: tun
 status: down
fw1# ifconfig tun2
tun2: flags=8011 rdomain 2 mtu 1500
 index 9 priority 0 llprio 3
 groups: tun
 status: down

# Start all SSL VPN tunnels (in unique VRF/rdomain's)
/usr/local/sbin/openvpn --config ./ch70.nordvpn.com.udp.ovpn --writepid
/var/run/openvpn.tun1.pid --dev tun1 &
/usr/local/sbin/openvpn --config ./ch71.nordvpn.com.udp.ovpn --writepid
/var/run/openvpn.tun2.pid --dev tun2 &
('auth-user-pass' updated in config files)

Each openvpn tunnel should start using 'rtable 0' for the VPN's outer
connection itself, but with each virtual tunnel TunX interface being placed
into a unique routing domain.

This results in the following tunX interface and rtable updates;
fw1# ifconfig
tun1

tun1: flags=8051 rdomain 1 mtu 1500
 index 6 priority 0 llprio 3
 groups: tun
 status: active
 inet 10.8.8.128 --> 10.8.8.1 netmask 0xff00
fw1# ifconfig tun2
tun2: flags=8051 rdomain 2 mtu 1500
 index 7 priority 0 llprio 3
 groups: tun
 status: active
 inet 10.8.8.129 --> 10.8.8.1 netmask 0xff00
fw1# route -T 1 show
Routing tables
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
10.8.8.1   10.8.8.128 UH 00 - 8
tun1
10.8.8.128 10.8.8.128 UHl00 - 1
tun1
localhost  localhost  UHl00 32768 1
lo1
fw1# route -T 2 show
Routing tables
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
10.8.8.1   10.8.8.129 UH 00 - 8
tun2
10.8.8.129 10.8.8.129 UHl00 - 1
tun2
localhost  localhost  UHl00 32768 1
lo2

# Test each tunnel - Ping the remote connected vpn peer within each rdomain
ping -V 1 10.8.8.1
ping -V 2 10.8.8.1

Shows both VPN tunnels are working independently with the overlapping
addressing :)

# To be able to test each tunnel beyond the peer IP, add some default
routes to the rdomains;
route -T 1 -n add default 10.8.8.1
route -T 2 -n add default 10.8.8.1

# Test each tunnel - Ping beyond the connected peer
ping -V 1 8.8.8.8
ping -V 2 8.8.8.8

Shows both VPN tunnels are definitely working independently with the
overlapping addressing :)

# Reverse routing - I have read in various places that PF's 'route-to' can
be used for jumping rdomains's in the forward path of the session, but the
reply packets need any matching route in the remote rdomain for the reply
destination (the matching route is to ensure in the reply packet is passed
through the routing table and gets into 

Re: IPSEC from behind NAT stage 2 failure

[Philip Higgins]

On 2016-12-06 12:05, Robert Szasz wrote:

I'm trying to set up an L2TP/IPSEC tunnel for roaming windows users to
tunnel in to our office network.

I'm testing with the following setup

Win10 ->obsd5.9(firewall doing nat)->{}->obsd5.9(IPSEC)



Windows needs a registry entry set for L2TP and IPSEC to work properly 
with NAT.

Seems to apply whether it is the server or client or both behind NAT.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:0002

https://support.microsoft.com/en-au/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t-device-in-windows-vista-and-in-windows-server-2008


-Phil

/usr/sbin/dhcpd -u pledge failure.

[Philip Higgins]

Hi,

When using 'udpsockmode' in dhcpd (-u flag), it first calls
pledge("stdio rpath inet sendfd proc id", NULL) (in udpsock.c)

then tries
pledge("stdio inet route sendfd", NULL) (back in dhcpd.c)

The "route" causes it to fail.

eg.
$ doas dhcpd -u -fd pppx0
Listening on 255.255.255.255:67/udp.
dhcpd: pledge: Operation not permitted

"route" isn't defined in the pledge(2) man page,
but testing seems to indicate it is necessary.

Index: udpsock.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/udpsock.c,v
retrieving revision 1.5
diff -u -p -r1.5 udpsock.c
--- udpsock.c   8 Feb 2016 02:06:07 -   1.5
+++ udpsock.c   4 Apr 2016 04:09:14 -
@@ -65,7 +65,7 @@ udpsock_startup(struct in_addr bindaddr)
error("setsocketopt IP_RECVIF failed for udp: %s",
strerror(errno));

-   if (pledge("stdio rpath inet sendfd proc id", NULL) == -1)
+   if (pledge("stdio rpath inet sendfd proc id route", NULL) == -1)
error("pledge: %s", strerror(errno));

sin4.sin_family = AF_INET;


--
-Phil

Re: tcpdump dhcp6 interpretation out of date

[Philip Higgins]

On Thu, Nov 12, 2009 at 6:35 PM, Claudio Jeker cje...@diehard.n-r-g.com wrote:

 Send a diff that updates the needed points and read it carefuly to make
 sure you did not pick up any of the buffer overflows in the parsers from
 tcpdump.org.

 --
 :wq Claudio

It's going to be a pretty big diff, the protocol changed a lot.
(ie. Instead of 6 different packet formats with a few extensions, it's got a
fixed header with any of about 50 possible options appended).

Would I be right in thinking it'll be more easily digested if I break
it up a bit?

The header parsing code would be a minimal patch, and
would solve most of the problem. Then the options could be done in a
couple of steps.

--
Philip Higgins

tcpdump dhcp6 interpretation out of date

[Philip Higgins]

I noticed while doing some debugging on an ipv6 connection that the
included version of tcpdump uses an old draft version of dhcp6 for
its output.

src/usr.sbin/tcpdump/dhcp6.h was last edited almost 10 years, and
is based on draft 14.

For a while I was a little confused why wide-dhcpdc was sending a
release packet every half hour, but it was really a renew packet.

I know I can just grab the latest code from tcpdump.org and build it,
but what's the best way to get this updated in tree?

Thanks
Philip Higgins

Re: Problems with 4.5 as a KVM guest

[Philip Higgins]

On Sun, Nov 1, 2009 at 5:54 PM, Garry Dolley gdol...@arpnetworks.com wrote:
 On Sat, Oct 31, 2009 at 09:42:58AM +0100, Michiel van Baak wrote:

 I tried to upgrade my 4.5 and got the same.
 Sorry, have no way around it for the moment. I reverted the vm back to
 it's previous working state.

 This is how I got OpenBSD 4.5 working:

 http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04


FWIW, this procedure works for 4.6 on Xen as well. The issue is probably
somewhere in the common QEMU code.

--
Philip Higgins