Home / server / Questions

Questions[site-to-site-vpn](server)

Martin Hope
appcoder
Asked: 2024-04-27 12:40:07 +0800 CST
  • 7

I have setup an Azure VPN gateway with a site to site VPN connection and the status of the VPN Connection is "Connected". I have also created an AKS cluster and an Azure VM in the same virtual network of the VPN Gateway. Now when I try to connect a remote ip address that is on the site in the remote network - it doesnt work - either from the Azure VM or the Azure VPN gateway. Ping or Tracert to the destination ip(NAT'ed ip address) doesnt work as well. Any ideas where the problem can be?

The output of netsh route

Publish  Type      Met  Prefix                    Idx  Gateway/Interface Name
-------  --------  ---  ------------------------  ---  ------------------------
No       Manual    0    0.0.0.0/0                  13  10.0.2.1
No       System    256  10.0.2.0/23                13  Ethernet
No       System    256  10.0.3.75/32               13  Ethernet
No       System    256  10.0.3.255/32              13  Ethernet
No       System    256  127.0.0.0/8                 1  Loopback Pseudo-Interface 1
No       System    256  127.0.0.1/32                1  Loopback Pseudo-Interface 1
No       System    256  127.255.255.255/32          1  Loopback Pseudo-Interface 1
No       Manual    1    168.63.129.16/32           13  10.0.2.1
No       Manual    1    169.254.169.254/32         13  10.0.2.1
No       System    256  224.0.0.0/4                 1  Loopback Pseudo-Interface 1
No       System    256  224.0.0.0/4                13  Ethernet
No       System    256  255.255.255.255/32          1  Loopback Pseudo-Interface 1
No       System    256  255.255.255.255/32         13  Ethernet
site-to-site-vpn
Martin Hope
Ben Butterworth
Asked: 2020-03-30 10:05:53 +0800 CST
  • 11

I know that site-to-site is using IPSec (layer 3), but client is using TLS (application layer). It seems like both are actually site to site vpns after reading articles/ docs online.

I guess the protocol (IPSec vs TLS) is their only difference, which has implications on when you would use which one. I would guess that both are equally good, and you should always use TLS on the application layer anyway, even on top of client VPN.

How do you decide which one to use, and why?

vpn site-to-site-vpn amazon-web-services
Martin Hope
Deneb
Asked: 2012-05-05 01:18:27 +0800 CST
  • 6

What I am trying to do is to create a site-to-site IPsec VPN between my network and my friend's network. We both have a router and two computers on each router, with all computers running Linux. So I guess the topology looks like this

[myPC1 + myPC2]---myRouter------internet-----hisRouter---[hisPC1 + hisPC2]

Both routers are cheap so they don't have anything like OpenWRT.

So the configuration – I guess that should be done in Linux on both sides.

So far we have tried with openSwan both with RSA keys and PSK but after the command 

ipsec auto --up net-to-net

we either get the error "no connection named net-to-net" or the error "We cannot identify ourselves with either end of this connection."

I guess we are configuring the ipsec.conf file wrong. Could someone explain how we should configure it correctly to achieve this topology, please?

EDIT...

Here are some facts that might help you understand better my case.
These are all from the PSK example we tested.

My ifconfig:

eth0 Link encap:Ethernet HWaddr 00:0C:29:1B:F5:1C
inet addr:192.168.1.78 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe1b:f51c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:829 errors:0 dropped:0 overruns:0 frame:0
TX packets:704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1213737 (1.1 MiB) TX bytes:57876 (56.5 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3664 (3.5 KiB) TX bytes:3664 (3.5 KiB)

His ifconfig

Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 b) TX bytes:240 (240.0 b)

p2p1 Link encap:Ethernet HWaddr 08:00:27:2A:F1:F5
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe2a:f1f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21104 errors:0 dropped:0 overruns:0 frame:0
TX packets:12458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16079321 (15.3 MiB) TX bytes:1012204 (988.4 KiB)

The ipsec.conf file, we both used the exact same file, we also placed it in /etc/init.d

version 2.0    
config setup    
    protostack=netkey    
    nat_traversal=yes    
    #virtual_private=    
    oe=off    

conn net-to-net  
    authby=secret                # Key exchange method  

    left=212.251.112.115         # Public Internet IP address of the
    leftsubnet=10.0.2.0/24       # Subnet protected by the LEFT VPN device  
    leftnexthop=%defaultroute    # correct in many situations  

    right=79.103.7.114           # Public Internet IP address of
    rightsubnet=192.168.1.0/24   # Subnet protected by the RIGHT VPN device  
    rightnexthop=%defaultroute   # correct in many situations

    auto=start                   # authorizes and starts this connection

We also used th exact same ipsec.secrets, which we both placed in /etc/init.d

212.251.112.115 79.103.7.114 : PSK "123"

we got those IPs with curl ifconfig.me After that configuration we run: 

service ipsec restart  
ipsec verify

and we got the same fail message in the send_redirects, which refused to change to 0

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.1.0-7.fc16.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

    [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

then we proceeded with 

ipsec auto --up net-to-net

and we both got

022 "net-to-net": We cannot identify ourselves with either end of this connection.

I don't know if it helps, perhaps you have already noticed what's wrong but here is one last thing, the status of ipsec:

ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.1.78
000 interface eth0/eth0 192.168.1.78
000 %myid = (none)
000 debug none
000 
000 virtual_private (%priv):
000 - allowed 0 subnets: 
000 - disallowed 0 subnets: 
000 WARNING: Either virtual_private= is not specified, or there is a syntax 
000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have 
000          private address space in internal use, it should be excluded!
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0} 
000 
000 "net-to-net": 10.0.2.0/24===212.251.112.115<212.251.112.115>[+S=C]---192.168.1.254...192.168.1.254---79.103.7.114<79.103.7.114>[+S=C]===192.168.1.0/24; unrouted; eroute owner: #0
000 "net-to-net":     myip=unset; hisip=unset;
000 "net-to-net":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "net-to-net":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24; interface: ; 
000 "net-to-net":   newest ISAKMP SA: #0; newest IPsec SA: #0;

One more question is how the NETKEY [Failed] problem could be solved, if it's necessary!

vpn linux site-to-site-vpn ipsec openswan
Martin Hope
DD.
Asked: 2012-04-20 02:24:19 +0800 CST
  • 6

I'm trying to connect to a counterparty using VPN IPsec. I have a standard cable broadband connection with a single static IP address. The counterparty have asked me for my "Public IP Address Assigned to VPN Device" and also my "Encryption Domain".

What exactly is an encryption domain? (Is this my internal IP address of the host machine).

vpn site-to-site-vpn encryption domain