DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 30th May 2015
WeakSauceIII WeakSauceIII is offline
Port Guard
 
Join Date: May 2008
Posts: 36
Default Route to enc0

So its been 6 years of problem free BSDing but im back.....

I have a remote network (amazon virtual private cloud) attached to my BSD gateway via ipsec in tunnel mode. I can access the internet thru my gateway and I can also access any server in that remote 10.x network from my home 192.x network. My question is how do you route to enc0? I have set the 10.x netowrk at amazon to use the VPN as the default gateway so traffic goes from 10.x server, across vpn to my 192.x bsd gateway. this traffic is then natted out to the internet, hits the remote destination, and the replies come back. Problem is my ipsec tunnel is

ike esp from 192.168.0.0/24 to 10.0.1.0/24

so when traffic is de-natted it is $externalIP - > 10.x instead of $internalIP - > 10.x so ipsec policy doesn't match and packet never gets back into enc0 or across the tunnel

Seems to me like the solution is to tunnel this traffic (gif0) so i can route it but the problem is i do no have access to the remote vpn server to configure any kind of tunnel interface on the far side. Any suggestions on how one would route return traffic into the ipsec tunnel in this case?
Reply With Quote
  #2   (View Single Post)  
Old 30th May 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Welcome back!

The enc(4) pseudo driver is for integrating IPSec protected traffic with PF for packet filtering, and for diagnostics with tcpdump(8). It's not a directly usable device for networking, because every packet runs through the pseudo device twice.

I've never tried it -- so I cannot give any guidance -- but you might be able to redirect the appropriate enc(4) traffic via PF rules. PF's route-to or reply-to rule options come to mind as possible tools. But be careful. The enc(4) man page states:
Quote:
... the use of translation rules to map and redirect network traffic requires some care. Packets destined to be IPsec processed are seen by the filter/translation engine twice, both before and after being IPsec processed. If a packet's translated address on the way back fails to match an existing IPsec flow, from the translated address to the original source address, it will be discarded by the filter. It is best to avoid this situation where possible, though a flow may be explicitly created to work around it.
There are very few of us here who use IPSec. You'll probably get better answers if you post your question to the misc@ mailing list. It's just as raucous as it was six years ago... and sometimes, just as helpful.

Last edited by jggimi; 30th May 2015 at 01:28 AM. Reason: typo
Reply With Quote
  #3   (View Single Post)  
Old 30th May 2015
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 429
Default

Interesting problem, and you've basically hit it on the head. BSDs are (AFAIK) all policy-based and not route based, unfortunately, mainly for reasons jggimi has pointed out about the enc interface.

The solution, however insane it may sound, would be to setup a flow specifically for that traffic. Unfortunately that means you'd be opening your AWS side to the internet, so heavy filtering would be suggested, both in terms of your security groups and your BSD pf.
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice.

Last edited by rocket357; 30th May 2015 at 01:44 AM.
Reply With Quote
  #4   (View Single Post)  
Old 30th May 2015
WeakSauceIII WeakSauceIII is offline
Port Guard
 
Join Date: May 2008
Posts: 36
Default

thanks all for the input. just for an update - it is the tunnel part that i lack. This is how you reference in routing. Most devices such as juniper,cisco,palo alto ect seem to do the tunnel for you automatically like npppd does for openbsd. In my case since i cant config the amazon side i have to figure out what tunnel settings to use. Right now I'm trying with a gif0. Below is from the amazon config doc for my vpn. I had a working ipsec vpn between endpoints without referencing or doing anything with those 169.x tunnel IPs.




Quote:

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.

The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.

The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface.

Outside IP Addresses:
- Customer Gateway : xx.xx.xx.xx :-)
- Virtual Private Gateway : 72.21.xx.xx

Inside IP Addresses
- Customer Gateway : 169.254.255.34/30
- Virtual Private Gateway : 169.254.255.33/30

Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes


#4: Static Routing Configuration:

To route traffic between your internal network and your VPC,
you will need a static route added to your router.

Static Route Configuration Options:

- Next hop : 169.254.255.33

You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over
the tunnels.
Reply With Quote
  #5   (View Single Post)  
Old 30th May 2015
WeakSauceIII WeakSauceIII is offline
Port Guard
 
Join Date: May 2008
Posts: 36
Default

this is what i got now for gif0 using real external IPs of course. Then i can add a route for 10.x to the 'next hop' described in the doc 169.254.255.33. Not working but i think im on the right track ...

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
priority: 0
groups: gif
tunnel: inet xx.xx.xx.xx -> 72.21.xx.xx
inet 169.254.255.34 --> 169.254.255.33 netmask 0xffff0000
Reply With Quote
  #6   (View Single Post)  
Old 30th May 2015
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 429
Default

There's a bit of an issue with utilizing the 169.254 tunnels.

Since OpenBSD is policy-based, you'll get a tunnel to the other 169.254 endpoints at AWS. That's it. You can't route traffic through the enc0 interface...so via the first two tunnels you can reach the other BGP endpoints and nothing more.

You *could* layer another tunnel on top (basically, use the same psk and public IPs, but give it the local LAN and remote LAN CIDRs instead of the 169.254 addresses. OpenBGPD can run on the 169.254 addrs, but you won't be able to actually *route* anything, and if your S2S tunnel dies, you have to move it manually, which defeats the purpose of BGP dynamic routing.

See more here:

http://www.linuxquestions.org/questi...bgp-vpn-36539/

Edit - also, if you are going to use gif interfaces for 169.254 addrs, you need to put them in a /30 per the config (255.255.255.252 or 0xfffffffc).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice.

Last edited by rocket357; 30th May 2015 at 03:20 AM.
Reply With Quote
  #7   (View Single Post)  
Old 30th May 2015
WeakSauceIII WeakSauceIII is offline
Port Guard
 
Join Date: May 2008
Posts: 36
Default

honestly i'm not sure what the 169.x addresses are for. My vpn will work across 1 hop with just this in the ipsec.conf

ike esp from 192.168.99.0/24 to 10.0.1.0/24 \
local 98.xx.xx.xx peer 72.xx.xx.xx \
main auth hmac-sha1 enc aes group modp1024 lifetime 28800 \
quick auth hmac-sha1 enc aes group modp1024 lifetime 3600 \
srcid 98.xx.xx.xx \
psk "***" \
tag amazon-vpc


is this right for gif0? using my outside addresses and pointing to those 169 endpoints?

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
priority: 0
groups: gif
tunnel: inet 98.xx.xx.xx -> 72.xx.xx.xx
inet 169.254.255.34 --> 169.254.255.33 netmask 0xfffffffc

i cant ping 169.254.255.33 and the vpn works only for 1 hop regardless of this gif0 interface
Reply With Quote
  #8   (View Single Post)  
Old 30th May 2015
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 429
Default

The link local (169.254.X.Y) addresses are used (in AWS's config) for BGP. The way we have it setup, a route-based IPSEC engine can do something like this (this would require the gif interfaces):

Code:
ike esp from 169.254.249.62 to 169.254.249.61 \
   local 98.xx.xx.xx peer 72.xx.xx.xx \
   main auth hmac-sha1 enc aes group modp1024 lifetime 28800 \
   quick auth hmac-sha1 enc aes group modp1024 lifetime 3600 \
   srcid 98.xx.xx.xx \
   psk "***" \
   tag amazon-vpc
ike esp from 169.254.249.54 to 169.254.249.53 \
   local 98.xx.xx.xx peer 72.xx.xx.xx \
   main auth hmac-sha1 enc aes group modp1024 lifetime 28800 \
   quick auth hmac-sha1 enc aes group modp1024 lifetime 3600 \
   srcid 98.xx.xx.xx \
   psk "***" \
   tag amazon-vpc
This would configure two tunnels between whatever link-local addresses your AWS VPN config gave you. Then you could run OpenBGPD to receive route advertisements from the AWS VPN endpoints (typically the VPC CIDR) and advertise back to AWS your routes (your local LAN routes), and that traffic would be routed via the link-local tunnels (i.e. if you ran a traceroute, you would see the link-local ips along the path).

Unfortunately, OpenBSD doesn't have a route-based IPSEC engine, nor does it have the option for configuring route-based IPSEC, so this doesn't work. A static configuration like you outlined is your best bet (you *could* setup the link-local tunnels, but they wouldn't be very useful since OpenBSD's policy would only route to the other link-local ip of the tunnel and no further, meaning you'd have to have another tunnel in addition to the link-local tunnels and OpenBGPD wouldn't be able to failover to a different tunnel if one went down).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice.

Last edited by rocket357; 30th May 2015 at 09:26 PM.
Reply With Quote
  #9   (View Single Post)  
Old 31st May 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Because SAs and Flows are defined by policy, gif(4), gre(4), and vxlan(4) can be used to provision IPSec solutions. Here is an example I deployed using gif(4). Implementation of VLANs (802.1Q) eliminated the need for this particular solution, so it is no longer provisioned.
Reply With Quote
Old 31st May 2015
WeakSauceIII WeakSauceIII is offline
Port Guard
 
Join Date: May 2008
Posts: 36
Default

Thanks jggimi - ironically that was one of the best examples i had found already :-). A major hurdle in my case is that i cannot configure details on the amazon side. Their vpn device exports a config with ipsec settings for you to use - part of which i posted earlier. So any solution I come up with has to be configured 100% on my side. I was intrigued by this post

http://undeadly.org/cgi?action=artic...5303&mode=flat

specifically one of the comments about it at the bottom...

Quote:
This method means that the ipsec tunnel encapsulation is done directly by the gif(4) interface (via a standard route table entry), there's no flow entry so ipsec is just used to encrypt things, it doesn't use ipsec's tunnel encapsulation code at all.

The device at the other side can use either method, it can either be setup the same way with a gif interface, *or* it can have a "standard" IPsec configuration (i.e. just using isakmpd, or using a cheap router that only supports ipsec and not gif).

This works because gif(4)'s tunnel encapsulation is exactly the same as used by IPsec. This is particularly useful for vpn concentrators; you can use it on the central side to allow you to redistribute vpn routes using a dynamic routing protocol, but the "client"/remote side doesn't even need to know that you are doing this, they can just configure a standard IPsec connection, no separate gif interface needed on their side.
Im sure you all get the gist. You basically manually build an ipsec tunnel using transport mode + gif instead of tunnel mode and the other side would not need to be changed at all from a standard ipsec tunnel config.

Last edited by WeakSauceIII; 31st May 2015 at 04:54 PM.
Reply With Quote
Old 1st June 2015
WeakSauceIII WeakSauceIII is offline
Port Guard
 
Join Date: May 2008
Posts: 36
Default

Just an update for everyone. Amazon doc says they don't support any kind of tunneling. I will continue to research this. For now I have this working by changing my ipsec.conf

from

ike esp from 192.168.0/24 to 10.0.1.0/24

to

ike esp from any to 10.0.1.0/24

this allows return traffic from external interface get back to 10.x at amazon per policy. thanks to rocket357 for pointing that out.
Reply With Quote
Old 1st June 2015
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 429
Default

I just now noticed your posts on misc. Sorry for not speaking up there, been busy with, well, life =)

I've been toying around with the gif + transport idea again, but I've been mostly unsuccessful thus far. Once I get back into the office tomorrow I may check what the AWS back ends are saying about that configuration so I can tweak my home config. I dunno. Not certain it'll be successful...but I'm hopeful heh.
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice.

Last edited by rocket357; 1st June 2015 at 07:46 PM.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Multi-Path or Route-To? SlyM OpenBSD General 25 1st July 2016 04:21 PM
No Route to Host rtwingfield FreeBSD Installation and Upgrading 9 25th May 2015 03:05 AM
route on openbsd hpabsdbeginner1 OpenBSD General 2 15th April 2014 07:17 PM
Openvpn pf/nat/route-to issue lasstoff OpenBSD Security 3 16th January 2012 12:28 PM
How to add static route using virtual NIC bsdplus Solaris 1 22nd August 2010 02:10 AM


All times are GMT. The time now is 10:34 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick