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. <[email protected]> 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. <[email protected] <mailto:[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.
