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. <[email protected]> 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 pf.conf >>> #declare variables >>> tcp_services = " { ssh, https, http } " >>> udp_services = " { domain } " >>> ext = " iwn0 " >>> >>> #tables >>> table <whitelist> 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 \ >>> 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 <sshdbruteforce> persist >>> table <httpdbruteforce> persist >>> table <bruteforce> persist file "/etc/bruteforce" >>> table <goodhosts> persist >>> >>> set skip on lo0 >>> >>> block drop in quick from { <bruteforce>, <httpdbruteforce>, >>> <sshdbruteforce> } >>> block drop >>> >>> pass in log on $ext proto udp from <goodhosts> to 155.138.139.17 port >>> {isakmp, ipsec-nat-t} tag IKED >>> pass in log on $ext proto esp from <goodhosts> 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. <[email protected]> wrote: >>>> Additional Info: >>>> >>>> This is an OpenBSD -current -> OpenBSD -current IKED connection. >>>> >
