Re: Using OpenBSD as an L2TP client with A ISP
* Stuart Henderson [2021-10-26 11:35:06]: > On 2021-10-26, Matt Dainty wrote: > > I'm currently using OpenBSD with an Andrews & Arnold vDSL connection so I > > have > > a pppoe(4) interface, etc. and this works for IPv4 & IPv6. > > > > The problem is because of the rubbish rural Openreach infrastructure here in > > the UK I only get a stable 3.5 Mb/s, however another ISP (Voneus) has been > > installing fibre in the area and can offer a 100+ Mb/s connection, but it > > looks > > like their network is all sorts of CGNAT and they don't seem to offer IPv6 > > addresses. > > > > So I figured I'll just use the A L2TP relay service and use this new fast > > connection to tunnel all of my traffic between the two ISPs and maintain the > > IPv4 & IPv6 addesses that A have assigned to me on my vDSL connection. > > > > Has anyone done this with OpenBSD? I understand xl2tpd is in ports but does > > This (aaisp l2tp) is exactly why I wrote the port for xl2tpd, though in > my case it was only for emergency use while a line was down. > > > everything work through the tunnel, including IPv6? I saw mention about 8-9 > > years ago that the pppd(8) that xl2tpd uses doesn't do IPv6. Is that still > > the > > case? > > Yes that's still the case about pppd(8) and IPv6. Unfortunately pppd(8) > upstream removed most OS support somewhere after the version we > currently have so updating it is decidedly non-trivial (I think there > might have been a few versions between ours, last real update in '98, > and the last one with BSD support, but it's quite far from what > upstream has now). NetBSD looks like it has an IPv6-aware ppp(4) and pppd(8) but I haven't peeked at the source at all, that's just from the man pages, I was still at the stage of figuring out if this was even viable. > AFAIK the only ppp code in OpenBSD that supports IPv6 inside PPP is pppoe(4). I taught pppoe(4) about RFC 4638 which I've relied on since, but that was 9+ years ago so I've lost my familiarity with that code. I'll have a look at the sources and do some research. Cheers Matt
Using OpenBSD as an L2TP client with A ISP
I'm currently using OpenBSD with an Andrews & Arnold vDSL connection so I have a pppoe(4) interface, etc. and this works for IPv4 & IPv6. The problem is because of the rubbish rural Openreach infrastructure here in the UK I only get a stable 3.5 Mb/s, however another ISP (Voneus) has been installing fibre in the area and can offer a 100+ Mb/s connection, but it looks like their network is all sorts of CGNAT and they don't seem to offer IPv6 addresses. So I figured I'll just use the A L2TP relay service and use this new fast connection to tunnel all of my traffic between the two ISPs and maintain the IPv4 & IPv6 addesses that A have assigned to me on my vDSL connection. Has anyone done this with OpenBSD? I understand xl2tpd is in ports but does everything work through the tunnel, including IPv6? I saw mention about 8-9 years ago that the pppd(8) that xl2tpd uses doesn't do IPv6. Is that still the case? Thanks Matt
Re: 4G mini PCI-e modem support?
* Patrick Wildt [2021-01-08 11:17:18]: > Am Fri, Jan 08, 2021 at 02:29:02PM + schrieb Peter Kay: > > There appear to be no 4G modem support at the moment, specifically a > > mini PCI-e one so I can stick it in a PC engines apu4d4 and have a > > backup connection. > > > > Presuming a driver would need to be written, but just checking if I've > > missed anything? > > There's umb(4). It supports USB's MBIM standard. There are some MBIM > compatible chips around, one for instance is this one: > > https://www.varia-store.com/de/produkt/87272-simcom-sim7600e-h-mpcie-eu-lte-cat-4-modul.html > > You'll probably need to switch it into MBIM mode once via a specific > AT-command over the serial, but otherwise it should do. > > I'm sure there are plenty of other MBIM-compatible devices, this is just > the one from the top of my head. Does this SIMCom card work under OpenBSD with umb(4)? I can see its device IDs were added to umsm(4) in 2018. I'm also looking for a mini PCIe 4G/LTE card to put in an APU4. I'm not sure an M.2 card will fit into the standard case with the added height of the M.2 <-> mini PCIe adapter so I'd prefer to just get a mini PCIe device and avoid the extra adapter. Are there any other umb(4)-compatible devices in a mini PCIe form factor I can look for that will work in Europe? Matt
OpenBSD IPsec and RFC 3884
Hi, The background to this question is this thread I raised in January: http://marc.info/?t=12633023283r=1w=1 I didn't have chance to continue with it then, but I had a need to revisit this recently so I dug up my notes again. I'm not sure how much of RFC 3884 [1] is actually pertinent to what I'm asking, but I'm basically wondering if it's possible to do what Stuart Henderson suggested in his last message, i.e. getting isakmpd to negotiate tunnel mode but actually setting up a transport mode SA with a peer on my OpenBSD host so that along with the encapsulation performed by the gif interface, the packet format ends up being the same as what the peer with its tunnel mode SA will send me. This I believe should fix the problem I initially discovered. I did notice in gif(4) this bit in BUGS: For example, you cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode. FSVO usually? If this isn't currently possible, where would one start modifying code given there's isakmpd(8), ipsecctl(8), and now iked(8) on the horizon? Thanks Matt [1] http://www.faqs.org/rfcs/rfc3884.html
Re: Using OpenBSD with Amazon's Virtual Private Cloud, IPsec issue
* Stuart Henderson s...@spacehopper.org [2010-01-12 17:02:39]: Their examples are using route-based VPNs (http://kb.juniper.net/KB4124, RFC3884), I'm not sure whether this is entirely possible here with our ipsec (policy-based), but you could try setting up tunnels between the gif tunnel endpoints i.e. 1.2.3.4 and 72.21.209.225, and a second between 1.2.3.4 and 72.21.209.193. These would take place of the tunnels between 192.168.23/24 and 10/24 (traffic between these networks would be routed in the usual way, taking the gif interfaces as point-to-point links). RFC3884 uses transport mode to secure the already encapsulated traffic whereas I have to use tunnel mode. This is a shame as this method would work fine on OpenBSD, I remember doing it previously with another network. Any attempts to negotiate a transport mode SA are refused and when I tried your suggestion of creating an SA between just the tunnel endpoints, it was successfully negotiated but the packets just get dropped by the remote end. I'll post on Amazon's forums and see if there's any plan to support the RFC3884 style way of doing this. Cheers Matt
Using OpenBSD with Amazon's Virtual Private Cloud, IPsec issue
Hi,
I'm trying to evaluate using OpenBSD with Amazon's Virtual Private Cloud as a
Customer Gateway in their EC2-speak. What you need to do is create a tunnel
to each of Amazon's two routers, use BGP to exchange routes across the tunnels
and protect all the traffic with IPsec.
I've got it mostly working, but I've hit an issue with the IPsec and I'm
hoping someone might know what's going on.
I've made the various API calls as per the getting started guide [1] and
have the configuration in the generic format which you can see an example of
in the network admin guide [2]. Assume my uplink address is 1.2.3.4 and I
have a BGP ASN of 65023, my network is 192.168.23.0/24 and the remote
network where my EC2 instances will appear is 10.0.0.0/24.
Here's what I've done, first create two gif(4) tunnels:
# ifconfig gif1 create
# ifconfig gif1 tunnel 1.2.3.4 72.21.209.225
# ifconfig gif1 169.254.255.2 169.254.255.1 prefixlen 32
# ifconfig gif2 create
# ifconfig gif2 tunnel 1.2.3.4 72.21.209.193
# ifconfig gif2 169.254.255.6 169.254.255.5 prefixlen 32
Add the following to /etc/ipsec.conf:
ike dynamic esp from 169.254.255.2 to 169.254.255.1 \
local 1.2.3.4 peer 72.21.209.225 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk XXX
ike dynamic esp from 169.254.255.6 to 169.254.255.5 \
local 1.2.3.4 peer 72.21.209.193 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk YYY
Run isakmpd and load those two tunnels:
# isakmpd -4 -K
# ipsecctl -f /etc/ipsec.conf
ipsecctl -s all confirms those are loaded and I can ping the two tunnel
endpoints successfully. I've added pf rules to allow ESP and UDP 500 on the
external interface and for now I'm skipping gif1, gif2 and enc0 to hopefully
exclude pf as a potential source of any trouble.
Now I've created /etc/bgpd.conf
AS 65023
router-id 1.2.3.4
listen on 127.0.0.1
listen on 169.254.255.2
listen on 169.254.255.6
group amazon {
remote-as 7224
holdtime 30
holdtime min 30
announce default-route
announce IPv6 none
announce IPv4 unicast
neighbor 169.254.255.1 {
local-address 169.254.255.2
}
neighbor 169.254.255.5 {
local-address 169.254.255.6
}
}
Fire up bgpd and confirm it's working:
# bgpctl show nexthop
Nexthop State
169.254.255.5valid gif2UP
169.254.255.1valid gif1UP
# route -n get 10.0.0.0
route to: 10.0.0.0
destination: 10.0.0.0
mask: 255.255.255.0
gateway: 169.254.255.6
interface: gif2
if address: 169.254.255.6
priority: 48 (bgp)
flags: UP,GATEWAY,DONE
use mtuexpire
24 0 0
Now here's where I've got stuck. If I try and ping an EC2 instance from my
network, I see the plain gif traffic leaving the external interface and gets
dropped by the remote router as it's not protected with IPsec. This makes
sense as there's no flow defined that will match that traffic, so I add two
further tunnels to /etc/ipsec.conf:
ike dynamic esp from 192.168.23.0/24 to 10.0.0.0/24 \
local 1.2.3.4 peer 72.21.209.225 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk XXX
ike dynamic esp from 192.168.23.0/24 to 10.0.0.0/24 \
local 1.2.3.4 peer 72.21.209.193 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk YYY
Now, only the latter tunnel gets configured, I'm guessing this is because the
from+to tuple is identical so I'm configuring the same tunnel twice just with
a different peer and key. As long as the routing decides to use the tunnel
that is configured between the second peer, everything works, I can ping and
SSH to my EC2 instance, but if it switches to the tunnel configured between
the first peer then it breaks.
Is it possible to have both configured somehow?
Thanks
Matt
[1] http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide/
[2] http://docs.amazonwebservices.com/AmazonVPC/2009-07-15/NetworkAdminGuide/
