Re: Iked/unbound ~ more info.
Stuart, I'm going to try just changing resolv.conf to 10.0.1.1 when connected to IKED. Either that or, like you say, unbound-control a stub in a script with ikectl couple. Thanks again! I'm understanding things a lot better now. Much appreciated! Dale
Re: Iked/unbound ~ more info.
On 2019-11-19, Dale C. wrote: > I don't know how unbound will be aware of iked couple/decouple, so I > wonder how I'd specify "as appropriate" in this case short of a DNS > failover from the remote side using forward-zones in unbound. It won't be aware unless you tell it. But if you're scripting you can use unbound-control's forward_remove/forward_add commands so could, for example, tell it to use your (known) server address. > I'll > take a look at unwind... unwind is more designed for doing things automatically (either recursing itself or picking up forwarders from DHCP), though you could set "forwarder" in the config file and reload it. Or if you're happy with an external provider you could set it to use e.g. 9.9.9.9 (which does support DoT) all the time.
Re: Iked/unbound ~ more info.
I don't know how unbound will be aware of iked couple/decouple, so I wonder how I'd specify "as appropriate" in this case short of a DNS failover from the remote side using forward-zones in unbound. I'll take a look at unwind... On 11/18/19, Dale C. wrote: > "I'd go for a local unbound or local unwind instance, listening for > queries on localhost, configured to use a forwarder as appropriate, plus > the bypass rule suggested in faq17." > > Right. > > Thanks again, > > Dale > > On 11/18/19, Dale C. wrote: >> Stuart, >> >> Hmmm, thanks for taking the time to write. I'll consider these things. >> >> My server has a static IP, and I'd also like to start looking at DNS >> over TLS. My client has a dynamic (shared even - cellular gateway) IP >> address. >> >> There are some implications there I'll also need to consider. Routing >> DNS through to the server which can do DoT would be difficult without >> accepting DNS config from the responder, no? >> >> Thank you, >> >> Dale >> >
Re: Iked/unbound ~ more info.
"I'd go for a local unbound or local unwind instance, listening for queries on localhost, configured to use a forwarder as appropriate, plus the bypass rule suggested in faq17." Right. Thanks again, Dale On 11/18/19, Dale C. wrote: > Stuart, > > Hmmm, thanks for taking the time to write. I'll consider these things. > > My server has a static IP, and I'd also like to start looking at DNS > over TLS. My client has a dynamic (shared even - cellular gateway) IP > address. > > There are some implications there I'll also need to consider. Routing > DNS through to the server which can do DoT would be difficult without > accepting DNS config from the responder, no? > > Thank you, > > Dale >
Re: Iked/unbound ~ more info.
Hi Dale, I had unbound working with iked for a short time. I actually configured the interface enc0 like so; ** Server hostname.enc0 inet 10.0.5.1 255.255.255.0 10.0.5.255 --- ** Server iked.conf ikev2 “roaming" passive esp \ from 0.0.0.0/0 to 0.0.0.0/0 \ local egress peer any \ psk "---" \ config protected-subnet 0.0.0.0/0 \ config address 10.0.5.0/24 \ config name-server 10.0.5.1 \ tag "IKED" As you can see I then added the IP of the enc0 interface in iked.conf "config name-server 10.0.5.1”. I then added the subnet 10.0.5.0/24 as an “allow “ in the unbound.conf access-control: 10.0.5.0/24 allow Though I too am not sure if this is a good way of using iked and unbound. In fact I actually stopped using this and just added a Public DNS server like 1.1.1.1. >From all my reading, I think it is not required to configure the enc0 >interface. Further testing using an OpenBSD iked client, I had very little success is making that work. For my scenario I have iPhones and MacBooks using the native ikev2 Apple client and they work fine. All the clients get the Public IP of the iked Server when they connect. Nino > On 19 Nov 2019, at 7:46 am, Dale C. wrote: > > I'm thinking you're correct Chuck, I can't route traffic for localhost > through iked... > > So... "It might be necessary to exclude this traffic from the > flows to ensure connections to services running locally (such as a > local resolver) > > ^ Then I'd have local dns while connected to my VPN? > > OH... queries to external nameservers will still go through the VPN > though? So it should be alright? > > I'd much rather be doing DNS on the responder localhost though... > isn't that the correct way here? > > So, I'll try that, but any better solution for openbsd -> openbsd iked > when both are using unbound localhost DNS would be appreciated :) > > It works. > > Thanks Chuck ;) > > On 11/18/19, Dale C. mailto:maatk...@gmail.com>> wrote: >> Chuck, >> >> Hey thanks for the information. Yeah I've tried having unbound listen >> on 10.0.1.2 (the VPN support net), that didn't work. I have not tried >> putting unbound on an external interface, and would like to avoid >> that. >> >> I've actually taken unbound out of the equation on both sides. >> Disabled unbound, commented supercede directive from dhclient and used >> public name servers on both ends - that didn't work. >> >> Today, I'll try some things again with the simplified pf confs. I'll >> get some output from pflog. I'll try putting unbound on the public IP. >> >> In the faq there are a few lines: >> >> "Since all traffic goes through the VPN, including traffic targeted at >> localhost, it might be necessary to exclude this traffic from the >> flows to ensure connections to services running locally (such as a >> local resolver) reach the right target. This can be achieved by adding >> a single line to /etc/ipsec.conf on the initiator: flow from >> 127.0.0.1/32 to 127.0.0.1/32 type bypass" >> >> ^ I'm confused by this, i excluded this ipsec bypass and the rdr-to >> rule in the responder pf conf. I would've expected that to work with >> DNS targeting localhost? I'm also not clear how `match out log on enc0 >> inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive? >> Packets do not evaluate further rules because there are no more inet >> packets after this? Does the position of this line in my initiator >> pf.conf seem reasonable? I think perhaps it should go up... >> >> Also this: "One caveat with using an OpenBSD client is that it doesn't >> send configuration requests to the responder to configure its IP, so >> the initiator needs to manually NAT its outgoing packets on the enc0 >> interface so that packets appear on the responder with an IP on the >> VPN subnet." >> >> I tried a config name-server directive on the initiator iked.conf, but >> because it wants to verify the host at load-time, I get iked start >> errors with it. *I think this is the reason anyway, I'll take a closer >> look today*... So, I'm kind of wondering if a seamless way to switch >> in and out of the VPN exists for openbsd clients? I should be able to >> `ikectl couple/decouple' and just have it work right, so I'm looking >> for a way to configure name-server in the iked.conf initiator ideally? >> >> I'll go through your post a few more times and try your suggestions, >> thank you very much! >> >> Dale >> >>> Chuck Wrote >>> I am not sure if you noticed but 127.0.0.1 is always local to the machine >>> using it. If you try routing with it the packets will never leave the >>> system. If they do somehow leave then the system getting them will >>> reject >>> it as the packet did not come from itself. I mention this as I see in >>> both resolve.conf files the nameserver is listed as 127.0.0.1 >>> >>> You might try instead to have the unbound listen on the inside (or even >>> the outside) address. Af
Re: Iked/unbound ~ more info.
Stuart, Hmmm, thanks for taking the time to write. I'll consider these things. My server has a static IP, and I'd also like to start looking at DNS over TLS. My client has a dynamic (shared even - cellular gateway) IP address. There are some implications there I'll also need to consider. Routing DNS through to the server which can do DoT would be difficult without accepting DNS config from the responder, no? Thank you, Dale
Re: Iked/unbound ~ more info.
On 2019-11-18, Dale C. wrote: > "Since all traffic goes through the VPN, including traffic targeted at > localhost, it might be necessary to exclude this traffic from the > flows to ensure connections to services running locally (such as a > local resolver) reach the right target. This can be achieved by adding > a single line to /etc/ipsec.conf on the initiator: flow from > 127.0.0.1/32 to 127.0.0.1/32 type bypass" > > ^ I'm confused by this, i excluded this ipsec bypass and the rdr-to > rule in the responder pf conf. On OpenBSD (and many other systems) IPsec works with "flows" which, for want of a better word, "steal" traffic so that it doesn't follow the routing table but instead matching traffic is diverted over the VPN. (This is the traditional way of handling IPsec; some systems also do "route based" IPsec which is a bit more straightforward for people who understand IP routing but that's not possible with OpenBSD without an additional tunnel interface). > I would've expected that to work with > DNS targeting localhost? I'm also not clear how `match out log on enc0 > inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive? > Packets do not evaluate further rules because there are no more inet > packets after this? Does the position of this line in my initiator > pf.conf seem reasonable? I think perhaps it should go up... NAT rules take place *after* traffic has been selected by flows. (This is why there's a special "srcnat" config in iked.conf/ipsec.conf to handle this). For this simple case with 0.0.0.0/0 I don't think you'll need to touch that, just the "flow from 127.0.0.1/32 to 127.0.0.1/32 type bypass" in ipsec.conf should do the trick. (Yes, ipsec.conf, even though you're using iked! iked doesn't have a way to handle setting up bypass flows itself other than the built-in very annoying "block IPv6 by default" mode that is enabled by default, so you need to defer to ipsec.conf + ipsecctl for this). > I tried a config name-server directive on the initiator iked.conf, but "config name-server" is something that would go on the responder side, but it's pointless if the only clients are iked. > I should be able to > `ikectl couple/decouple' and just have it work right, so I'm looking > for a way to configure name-server in the iked.conf initiator ideally? I'd go for a local unbound or local unwind instance, listening for queries on localhost, configured to use a forwarder as appropriate, plus the bypass rule suggested in faq17.
Re: Iked/unbound ~ more info.
I'm thinking you're correct Chuck, I can't route traffic for localhost through iked... So... "It might be necessary to exclude this traffic from the flows to ensure connections to services running locally (such as a local resolver) ^ Then I'd have local dns while connected to my VPN? OH... queries to external nameservers will still go through the VPN though? So it should be alright? I'd much rather be doing DNS on the responder localhost though... isn't that the correct way here? So, I'll try that, but any better solution for openbsd -> openbsd iked when both are using unbound localhost DNS would be appreciated :) It works. Thanks Chuck ;) On 11/18/19, Dale C. wrote: > Chuck, > > Hey thanks for the information. Yeah I've tried having unbound listen > on 10.0.1.2 (the VPN support net), that didn't work. I have not tried > putting unbound on an external interface, and would like to avoid > that. > > I've actually taken unbound out of the equation on both sides. > Disabled unbound, commented supercede directive from dhclient and used > public name servers on both ends - that didn't work. > > Today, I'll try some things again with the simplified pf confs. I'll > get some output from pflog. I'll try putting unbound on the public IP. > > In the faq there are a few lines: > > "Since all traffic goes through the VPN, including traffic targeted at > localhost, it might be necessary to exclude this traffic from the > flows to ensure connections to services running locally (such as a > local resolver) reach the right target. This can be achieved by adding > a single line to /etc/ipsec.conf on the initiator: flow from > 127.0.0.1/32 to 127.0.0.1/32 type bypass" > > ^ I'm confused by this, i excluded this ipsec bypass and the rdr-to > rule in the responder pf conf. I would've expected that to work with > DNS targeting localhost? I'm also not clear how `match out log on enc0 > inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive? > Packets do not evaluate further rules because there are no more inet > packets after this? Does the position of this line in my initiator > pf.conf seem reasonable? I think perhaps it should go up... > > Also this: "One caveat with using an OpenBSD client is that it doesn't > send configuration requests to the responder to configure its IP, so > the initiator needs to manually NAT its outgoing packets on the enc0 > interface so that packets appear on the responder with an IP on the > VPN subnet." > > I tried a config name-server directive on the initiator iked.conf, but > because it wants to verify the host at load-time, I get iked start > errors with it. *I think this is the reason anyway, I'll take a closer > look today*... So, I'm kind of wondering if a seamless way to switch > in and out of the VPN exists for openbsd clients? I should be able to > `ikectl couple/decouple' and just have it work right, so I'm looking > for a way to configure name-server in the iked.conf initiator ideally? > > I'll go through your post a few more times and try your suggestions, > thank you very much! > > Dale > >> Chuck Wrote >> I am not sure if you noticed but 127.0.0.1 is always local to the machine >> using it. If you try routing with it the packets will never leave the >> system. If they do somehow leave then the system getting them will >> reject >> it as the packet did not come from itself. I mention this as I see in >> both resolve.conf files the nameserver is listed as 127.0.0.1 >> >> You might try instead to have the unbound listen on the inside (or even >> the outside) address. After that only allow access to it from the IKE >> networks. >> >> I would also mention that rdr-to is not NAT. It does reroute the packets >> but the return packets can take a different route. If the unbound is >> listening on 127.0.0.1 then that is where the packets will be coming >> from. >> You would need to NAT the outgoing DNS packets to the correct interface. >> >> No idea if any of this will help you. >> >> >> I did see a request on pflog, here is a really brief run down on how it >> is >> used. >> >> 1. Add 'log' to one of the rules. Ex rule from your pf rules: >> #name servers >> pass out log on $ext proto udp from $ext to any port $udp_services >> >> 2. View the pflog after some of the packets have been captured. Ex: >> /usr/sbin/tcpdump -n -e -ttt -s1500 -r /var/log/pflog >> >> This will display the packets in tcpdump format. The -e option is to >> give >> you the rule number that captured the packet, in case you have multiple >> logging rules. You can get the rule number from your pf.conf file by >> doing: /usr/sbin/pf -nvvvf /etc/pf.conf >> >> The -n is so the rules do not reload. The rule is @# >> >> >> Have Fun! >> Chuck Hall >> >> >>> Update: >>> >>> Spent a lot of time trying different things, still no DNS. >>> >>> Simplified and cleaned up all my confs as much as possible. >>> >>> Everything works, but DNS. >>> >>> ##initiator
Re: Iked/unbound ~ more info.
Chuck,
Hey thanks for the information. Yeah I've tried having unbound listen
on 10.0.1.2 (the VPN support net), that didn't work. I have not tried
putting unbound on an external interface, and would like to avoid
that.
I've actually taken unbound out of the equation on both sides.
Disabled unbound, commented supercede directive from dhclient and used
public name servers on both ends - that didn't work.
Today, I'll try some things again with the simplified pf confs. I'll
get some output from pflog. I'll try putting unbound on the public IP.
In the faq there are a few lines:
"Since all traffic goes through the VPN, including traffic targeted at
localhost, it might be necessary to exclude this traffic from the
flows to ensure connections to services running locally (such as a
local resolver) reach the right target. This can be achieved by adding
a single line to /etc/ipsec.conf on the initiator: flow from
127.0.0.1/32 to 127.0.0.1/32 type bypass"
^ I'm confused by this, i excluded this ipsec bypass and the rdr-to
rule in the responder pf conf. I would've expected that to work with
DNS targeting localhost? I'm also not clear how `match out log on enc0
inet all nat-to 10.0.5.2' behaves, is it akin to a "quick" directive?
Packets do not evaluate further rules because there are no more inet
packets after this? Does the position of this line in my initiator
pf.conf seem reasonable? I think perhaps it should go up...
Also this: "One caveat with using an OpenBSD client is that it doesn't
send configuration requests to the responder to configure its IP, so
the initiator needs to manually NAT its outgoing packets on the enc0
interface so that packets appear on the responder with an IP on the
VPN subnet."
I tried a config name-server directive on the initiator iked.conf, but
because it wants to verify the host at load-time, I get iked start
errors with it. *I think this is the reason anyway, I'll take a closer
look today*... So, I'm kind of wondering if a seamless way to switch
in and out of the VPN exists for openbsd clients? I should be able to
`ikectl couple/decouple' and just have it work right, so I'm looking
for a way to configure name-server in the iked.conf initiator ideally?
I'll go through your post a few more times and try your suggestions,
thank you very much!
Dale
On 11/18/19, ch...@qatland.com wrote:
> I am not sure if you noticed but 127.0.0.1 is always local to the machine
> using it. If you try routing with it the packets will never leave the
> system. If they do somehow leave then the system getting them will reject
> it as the packet did not come from itself. I mention this as I see in
> both resolve.conf files the nameserver is listed as 127.0.0.1
>
> You might try instead to have the unbound listen on the inside (or even
> the outside) address. After that only allow access to it from the IKE
> networks.
>
> I would also mention that rdr-to is not NAT. It does reroute the packets
> but the return packets can take a different route. If the unbound is
> listening on 127.0.0.1 then that is where the packets will be coming from.
> You would need to NAT the outgoing DNS packets to the correct interface.
>
> No idea if any of this will help you.
>
>
> I did see a request on pflog, here is a really brief run down on how it is
> used.
>
> 1. Add 'log' to one of the rules. Ex rule from your pf rules:
> #name servers
> pass out log on $ext proto udp from $ext to any port $udp_services
>
> 2. View the pflog after some of the packets have been captured. Ex:
> /usr/sbin/tcpdump -n -e -ttt -s1500 -r /var/log/pflog
>
> This will display the packets in tcpdump format. The -e option is to give
> you the rule number that captured the packet, in case you have multiple
> logging rules. You can get the rule number from your pf.conf file by
> doing: /usr/sbin/pf -nvvvf /etc/pf.conf
>
> The -n is so the rules do not reload. The rule is @#
>
>
> Have Fun!
> Chuck Hall
>
>
>> Update:
>>
>> Spent a lot of time trying different things, still no DNS.
>>
>> Simplified and cleaned up all my confs as much as possible.
>>
>> Everything works, but DNS.
>>
>> ##initiator pf.conf
>> #declare variables
>> tcp_services = " { ssh, https, http } "
>> udp_services = " { domain } "
>> ext = " iwn0 "
>>
>> #tables
>> table persist { 155.138.139.17 }
>>
>> set skip on lo0
>>
>> block drop
>>
>> #sshserver
>> pass in log on $ext proto tcp from any to port 22 synproxy state
>>
>> #name servers
>> pass out log on $ext proto udp from $ext to any port $udp_services
>>
>> #Serving dns on lan
>> pass in on $ext proto udp from 192.168.0.0/24 to any port $udp_services
>>
>> #State
>> pass out keep state
>>
>> #roadwarrior
>> match out log on enc0 inet all nat-to 10.0.1.2
>>
>> ##initiator iked.conf
>>
>> ikev2 'roadwarrior' active esp \
>> from 0.0.0.0/0 to 0.0.0.0/0 \
>> peer 155.138.139.17 \
>> srcid roadwarrior
Re: Iked/unbound ~ more info.
> On Nov 17, 2019, at 11:45 AM, Dale C. wrote: > > Hi again, > > Still trying to forward DNS to a local unbound resolver on the > responder of an IKE tunnel. > > Providing more information here. Everything works, but DNS. > > It's worth noting I've tried many, many variations on these configs, > cannot get DNS to the remote unbound resolver. > > So, my questions are: What is the correct way to forward DNS to a > local unbound resolver on the responder? > > If there is more information that is helpful, please let me know what > you need and I'll post it ;) > > Thanks! Dale Is it possible to place the ESP nterface in debug? Can you log PF/UDP traffic on the local unbound? Regards Patrick
