No problem. I guess I should add that I'm not NATing enc0 as my subject suggests. I just have the usual 'match out on $ext_if...' nat rule in pf.conf and a 'set skip on enc0'. The real solution was understanding that ipsec tunnel in openbsd doesn’t use the route table so looking for a way to 'static route' ipsec /enc0 is nonsensical. This lack of automatic routable ipsec interface is probably not a big deal to the community because you can just make your own tunnel to get a routable interface assuming you can config both sides. It's only a problem in cases like mine where the other end of the vpn gives you a take it leave it config.
-----Original Message----- From: Adam Van Ymeren [mailto:adam.v...@gmail.com] Sent: Monday, June 1, 2015 2:16 PM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: NATing out enc0 traffic Thanks for posting your adventure. I didn't have enough PF knowledge to help debug, but it was an interesting read. On Mon, Jun 1, 2015 at 3:11 PM, Justin Mayes <jma...@careered.com> wrote: > I have this working. After learning more about route vs policy ipsec tunnels > I added a policy for 'any' to 10.x and return traffic from the net is now > passed back. I will go back to my cave now.... > > > -----Original Message----- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Justin Mayes > Sent: Friday, May 29, 2015 11:10 AM > To: misc@openbsd.org > Subject: Re: NATing out enc0 traffic > > I think I am understanding this better after some more reading. My > ipsec tunnel just connects the two subnets and when my nat traffic > returns from the internet it does not match the policy for the tunnel > because the source address is not 192.x. What I need is some tunneling > protocol that I can route like pptp or l2tp which is what npppd is > for. I do not have access to configure the amazon side of the vpn for > pptp or l2tp so I do not think this is not going to be possible. That > seems odd. I assumed this would be a common setup > > -----Original Message----- > From: Justin Mayes > Sent: Thursday, May 28, 2015 1:52 PM > To: misc@openbsd.org > Subject: RE: NATing out enc0 traffic > > I just wanted to send an update based on some feedback. My subject is > misleading so let me clarify. I'm not attempting to nat between the networks > on either side of the vpn. For examples sake assume 192.168.0.0/24 on one > side of tunnel and 10.10.10.0/24 on the other. I'm trying to allow servers > on one side 10.x of the tunnel to access the internet via the other side of > the tunnel 192.168.0.1. Egress works, 10.x client gets to the internet and > replies come back. The return traffic comes back and the gateway drops it. I > assume that pf translates it back to the 10.x address and has no route for > that. I need it to go back through enc0. > > J > > -----Original Message----- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Justin Mayes > Sent: Wednesday, May 27, 2015 2:47 PM > To: misc@openbsd.org > Subject: NATing out enc0 traffic > > Greetings everyone > > I am playing with amazon virtual private clouds (VPC). I have set a few up. I > have no issues connecting ipsec from openbsd <-> amazon VPC. All of these > VPCs so far have their own internet connection going out from amazon that > works fine. > > > [OpenBSD]<--------ipsec--------->[VPC]<----------------->Internet > > > Next I am setting up a VPC that has no internet gateway. Instead the default > gateway is the vpn and all traffic is sent back through the ipsec tunnel and > then out the local network gateway. > > [Internet] > ^ > | > | > | > [OpenBSD]<-------ipsec------>[VPC] > > > I added these relevant lines to pf.conf > > Match out on $ext_if from !($ext_if:network) nat-to ($ext_if) pass > quick on enc0 keep state (if-bound) > > With tcpdump and pfctl I can tell that traffic from the vpc (10.0.0.0/8) > comes across the tunnel and gets NATed out. I can see that traffic leave the > external interface and I can see the reply come back to the external > interface. The reply never hits enc0 though and never makes it back to the > client. Is there another piece to the setup I am missing? I assume what I am > trying to do is possible. I would appreciate any insight or advice anyone may > have in regards to this type of setup. > > J
