I have the following setup:
|---> <VIA ipsec 172.20.0.0/16, reachable from the LAN>
<LAN 192.168.200.11/22> ----+
|---> <VIA ipsec 10.64.0.0/16, reachable from the LAN>
If I try to set the system to use 172.20.100.34 as a DNS server it doesn't get any response,
same with 10.64.0.4.
If I ping using -S 192.168.200.11 it all works.
What am I missing in the routing tables?
root@home-fw:~ # netstat -rn |more
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 76.250.252.1 UGS ngeth0
10.64.0.0/16 10.128.0.2 UGS ipsec100
10.128.0.1 link#18 UHS lo0
10.128.0.2 ipsec1000 UHS ipsec100
10.128.0.3 link#19 UHS lo0
10.128.0.4 ipsec1000 UHS ipsec200
76.250.252.0/22 link#11 U ngeth0
76.250.255.117 link#11 UHS lo0
127.0.0.1 link#7 UH lo0
172.20.0.0/16 10.128.0.4 UGS ipsec200
172.31.0.0/16 10.128.0.4 UGS ipsec200
192.168.16.0/24 link#15 U em0_vlan
192.168.16.1 link#15 UHS lo0
192.168.17.0/24 link#16 U em0_vlan
192.168.17.1 link#16 UHS lo0
192.168.18.0/24 link#17 U em0_vlan
192.168.18.1 link#17 UHS lo0
192.168.40.0/24 link#12 U em0_vlan
192.168.40.1 link#12 UHS lo0
192.168.64.0/24 link#13 U em0_vlan
192.168.64.1 link#13 UHS lo0
192.168.192.0/24 link#14 U em0_vlan
192.168.192.1 link#14 UHS lo0
192.168.200.0/22 link#1 U em0
192.168.200.11 link#1 UHS lo0
Did you try setting outgoing interface for Unbound as LAN?
Otherwise you could also add your WAN IP/32 as a second Phase2 ...
could you be more specific on adding the WAN/32 as a 2nd phase2 and can that appear in BOTH Tunnels?
I'm looking for the system itself (not just unbound) to be able to use stuff off the tunnels).
Specifics would be appreciated.
...
I have the following setup:
|---> <VIA ipsec 172.20.0.0/16, reachable from the LAN>
<LAN 192.168.200.11/22> ----+
|---> <VIA ipsec 10.64.0.0/16, reachable from the LAN>
...
So you have two tunnel, both with one Phase2:
192.168.200.0/22 <-> 172.20.0.0/16
and
192.168.200.0/22 <-> 10.64.0.0/16
And after this you have:
192.168.200.0/22 <-> 172.20.0.0/16
WAN-IP-of-OPN/32 <-> 172.20.0.0/16
and
192.168.200.0/22 <-> 10.64.0.0/16
WAN-IP-of-OPN/32 <-> 10.64.0.0/16
What are the *EXACT* settings on the phase 2 page.
This a route-based tunnel.
Thanks for any help.
Quote from: lrosenman on September 04, 2019, 11:32:13 AM
What are the *EXACT* settings on the phase 2 page.
This a route-based tunnel.
These are the exact settings for policy-based .. never did with route-based. I'd stay away from route-based unless there's a real need for it.
Azure (the destination) doesn't do policy based, and I don't want ALL the traffic to go via Azure.
Hm, so when you have a route in routing table, OPNsense should use as source address the one assigned to the IPSEC interface. If you add this address in the routing table on Azure side, doesn't this work? Just a guess ..
To be clear, the VPN Gateway I set up on the Azure side is a Route Based VPN.
I followed this guide:
https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-route-azure.html
What do I need to add/use? or doesn't this work to have the fw use the tunnels itself?
In this picture:
https://wiki.opnsense.org/_images/xipsec_s2s_route_azure_lng.png.pagespeed.ic.28tVXs-0if.webp
Address space, there is the tunnel IP of OPNsense with /32, is this also on your side? Since this IP should be seen by Azure and OPN should already use this as source address.
the /32 is actually the gateway address:
https://www.lerctr.org/~ler/lng.png
I don't think we want it to appear twice.
I've actually tried adding it, and no dice, FWIW.
Quote from: lrosenman on September 04, 2019, 12:10:36 PM
the /32 is actually the gateway address:
https://www.lerctr.org/~ler/lng.png
I don't think we want it to appear twice.
In this guide it's the tunnel address inside of the VPN, not the gateway IP.
adding that does NOT change anything. >:(
What do you see with a packet capture on your assgined IPsec interface?
root@home-fw:~ # tcpdump -XX -vv -s 0 -i ipsec2000 dst host 10.64.0.4
tcpdump: listening on ipsec2000, link-type NULL (BSD loopback), capture size 262144 bytes
nothing (even for LAN->IPSEC traffic0
Hm, and enc0 also nothing?
Bingo. I had screwed up which address was in which VPN. tcpdump on enc0 had me see the correct source address, and having added the correct 10.128* address to the local network gateway on Azure makes it work.
THANK YOU.
Great! 8)