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.
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.
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'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 multip
Re: Iked/unbound ~ more info.
68.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 \
>> dstid deceptions.ca
>>
>> ##initiator resolv.conf
>>
>> # Generated by iwn0 dhclient
>> nameserver 127.0.0.1
>> lookup file bind
>>
>> ##initiator ipsec.conf
>> #flow from 127.0.0.1/32 to 127.0.0.1/32 type bypass
>> #this is commented, but tried both ways on initiator
>> #with it commented, it should go to the responder localhost
>> #which is exactly where i want it.
>>
>> ##responder pf.conf
>> ext = " vio0 "
>>
>> table persist
>> table persist
>> table persist file "/etc/bruteforce"
>> table persist
>>
>> set skip on lo0
>>
>> block drop in quick from { , ,
>> }
>> block drop
>>
>> pass in log on $ext proto udp from to 155.138.139.17 port
>> {isakmp, ipsec-nat-t} tag IKED
>> pass in log on $ext proto esp from to 155.138.139.17 tag IKED
>> pass in log on enc0 tagged ROADW
>> match out log on $ext inet tagged ROADW nat-to $ext
>> match in quick on enc0 inet proto { tcp, udp } to port 53 rdr-to
>> 127.0.0.1 port 53
>> #tried both with and without ^ this line on both conditions of
>> initiator ipsec.conf
>> #neither worked
>>
>> #sshd
>> pass in log on $ext proto tcp from any to port 22 synproxy state
>> (source-track rule, max-src-states 10, max-src-conn 10,
>> max-src-conn-rate 3/60, overl>
>>
>> #httpd
>> pass in log on $ext proto { tcp } from any to port {80, 443} modulate
>> state (source-track rule, max-src-states 10, max-src-conn 10,
>> max-src-conn-rate >
>>
>> #mail
>> pass in log on $ext proto tcp from any to port 25 modulate state
>> (source-track rule, max-src-states 20, max-src-conn 20,
>> max-src-conn-rate 20/600, ove>
>>
>> # By default, do not permit remote connections to X11
>> block return in on ! lo0 proto tcp to port 6000:6010
>>
>> # Port build user does not need network
>> block drop quick on any proto {tcp udp} user _pbuild
>>
>> pass out keep state
>>
>> ##responder iked.conf
>>
>> ikev2 'responder_rsa' passive esp \
>> from 0.0.0.0/0 to 10.0.1.0/24 \
>> local 155.138.139.17 peer any \
>> srcid deceptions.ca \
>> tag "ROADW"
>>
>> ##responder unbound.conf
>>
>> # $OpenBSD: unbound.conf,v 1.19 2019/11/07 15:46:37 sthen Exp $
>>
>> server:
>> outgoing-interface: 155.138.139.17
>> interface: 127.0.0.1
>> #interface: ::1
>> do-ip6: no
>>
>> access-control: 0.0.0.0/0 refuse
>> access-control: 10.0.0.0/8 allow
>> access-control: 127.0.0.0/8 allow
>> #access-control: ::0/0 refuse
>> #access-control: ::1 allow
>>
>> #Files
>> root-hints: "/var/unbound/etc/root.hints"
>> pidfile: "/var/unbound/unbound.pid"
>>
>> #DNS Validation
>> auto-trust-anchor-file: "/var/unbound/db/root.key"
>> val-log-level: 2
>>
>> #logging
>> logfile: "/var/unbound/unbound.log"
>> verbosity: 2
>>
>> #NeverUseDeez
>> private-address: 192.168.0.0/16
>> private-address: 172.16.0.0/12
>> private-address: 10.0.0.0/8
>> private-domain: "local."
>>
>> #HardenOptions
>> harden-glue: yes
>> harden-dnssec-stripped: yes
>> hide-identity: yes
>> hide-version: yes
>> aggressive-nsec: yes
>>
>> #OtherOptions
>> #use-caps-for-id: yes
>> #prefetch: yes
>> minimal-responses: yes
>> do-not-query-localhost: no
>>
>> remote-control:
>> control-enable: yes
>> control-interface: /var/run/unbound.sock
>>
>> ##responder resolv.conf
>>
>> # Generated by vio0 dhclient
>> nameserver 127.0.0.1
>> lookup file bind
>> private-address: 192.168.0.0/16
>>
>>
>> On 11/17/19, Dale C. wrote:
>>> Additional Info:
>>>
>>> This is an OpenBSD -current -> OpenBSD -current IKED connection.
>>>
Re: Iked/unbound
I'm not seeing anything helpful there. I have worked out the pf problem, still have difficulty with how to pass DNS to the resolver on the responder. Dale On 11/16/19, Clay Daniels wrote: > Check out this: > > https://man.openbsd.org/iked.8 > > History > > The iked program was written by Matthew Grooms ( mgro...@shrew.net ) as > part of the Shrew Soft ( http://www.shrew.net ) family of IPsec products. > > On Sat, 16 Nov 2019, Dale C. wrote: > >> Date: Sat, 16 Nov 2019 12:44:21 -0700 >> From: Dale C. >> To: misc@openbsd.org >> Subject: Iked/unbound >> >> Hi there, >> >> I'm trying to setup iked. I have it working with the exception of DNS. >> >> I've put the responders conf files here: https://bpaste.net/raw/LH4O2 >> >> My question is, what is the right way to forward DNS to a local >> unbound resolver on the responder? >> >> I'm also not sure why I need the line: pass in quick from >> in the responders pf.conf... I can't connect without it, though the >> preceeding lines should be allowing that connection? >> >> Thanks for any clarification! >> >> Dale >> >> > > clays.sh...@sdf.org > SDF Public Access UNIX System - http://sdf.org >
Iked/unbound
Hi there, I'm trying to setup iked. I have it working with the exception of DNS. I've put the responders conf files here: https://bpaste.net/raw/LH4O2 My question is, what is the right way to forward DNS to a local unbound resolver on the responder? I'm also not sure why I need the line: pass in quick from in the responders pf.conf... I can't connect without it, though the preceeding lines should be allowing that connection? Thanks for any clarification! Dale
