Hi,
I have a VPN to a Customers Network which is basically working as expected, but it it won't come up on traffic. Even with the "Start immediately" Switch set the Connection starts, but it disconnecs at some point when idle and the only way to bring it up is to connect manually.
Situation:
- Tunnel IP4 VPN
- no control over the remote side
- no problem in IPsec Configuration
- only one direction - outgoing
- I have to SNAT my Network to a single address provided by the remote side. This is most likely the Showstopper, but I don't have an Idea on how to workaround.
Any suggestions?
Thanks,
juergen
So you have
'single address provided by the remote side'<=======>RemoteNetwork
and
LocalNetWork which needs to get SNATted to this 'single address'
In my experience, you will not be able to initiate correctly from your side as:
* SNAT will happen AFTER traffic is passed to the tunnel
* when the tunnel is not up, this will not happen.
What you need:
* put your local network into the 'Additional SPF' Field in the phase two entry, obviously.
* use a stupid hack to keep the tunnel up, or initiate. For this last step I assign the 'single address' as an additional IP on my 'Local Network', and I use a cronjob that does something like 'ping -c 2 -S 'single address' 'some address in the remote network'
That runs every minute, sends two pings through the tunnel and initiates the connection if need be.
Hope this helps,
Frank
PS: if somebody knows of a less kludgy solution. I'm interested
Already found the "Additional SPF" Setting.
For the ping method I am not sure how this could work.
By using the "single address" as Source, these Packets even will not be able reach the gateway's LAN Interface which has an ip from "Local Network":
# traceroute -n -s "single address" "IP in Remote Net"
traceroute to "IP in Remote Net", 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
Am I missing something?
Thank you,
juergen
ipsec status probably shows you something like this;
con1{15}: ROUTED, TUNNEL, reqid 1
con1{15}: 185.3.137.0/26 === 182.32.0.199/32
only traffic originating from 182.32.0.199 will cause the tunnel to initiate from your side.
so in this case ping -S 182.32.0.199 185.3.137.1 would match the traffic selector.
seems a bit different here :
con3{28}: ROUTED, TUNNEL, reqid 1
con3{28}: 192.168.254.0/24 === 172.16.20.8/32
and
root@OPNsense:~ # pfctl -s state | grep 193.186.104
all tcp 193.186.104.36:52813 (192.168.254.69:61546) -> 172.27.24.129:3389 ESTABLISHED:ESTABLISHED
yes, you have different IPs than mine (which were edited).
ok, forget about the last one , it's gettin more confusing to me :-[
The Natt'ed tunnel in Question doesn't appear unter "Routed Connections" even if I bring it up manually.
Routed Connections:
con5{30}: ROUTED, TUNNEL, reqid 5
con5{30}: 192.168.254.0/24 === 10.80.1.0/24
con4{29}: ROUTED, TUNNEL, reqid 2
con4{29}: 192.168.254.0/24 === 10.1.10.0/23
con3{28}: ROUTED, TUNNEL, reqid 1
con3{28}: 192.168.254.0/24 === 172.16.20.8/32
con1{26}: ROUTED, TUNNEL, reqid 4
con1{26}: 192.168.254.0/24 === 192.168.10.0/24
Security Associations (5 up, 0 connecting):
...snip...
con2[164]: ESTABLISHED 40 seconds ago, mygateway...remotegateway
con2{70}: INSTALLED, TUNNEL, reqid 8, ESP SPIs: c2c93be5_i 1fae9593_o
con2{70}: 193.186.104.36/30 === 172.27.24.0/24
...snip...
193.186.104.36 is the IP Adress I got from remote side to use, 172.27.24.0/24 is the remote LAN.
To me it looks like no route for the remote net is installed.
???