SSL VPN : Site-to-Site SSL and Remote Access SSL VPN : Ubiquiti EdgeOS as Client

RE: SSL VPN : Site-to-Site SSL and Remote Access SSL VPN : Ubiquiti EdgeOS as Client

BAlfson — Sat, 11 Sep 2021 20:33:47 GMT

That looks great, André! Thanks for sharing and helping the next person that needs to make the same connection.

Cheers - Bob

RE: SSL VPN : Site-to-Site SSL and Remote Access SSL VPN : Ubiquiti EdgeOS as Client

relume — Sat, 11 Sep 2021 09:31:46 GMT

Hello Bob

Many thanks for your reply and your considerations/hints. I am sorry to get back only today - I had some difficulty to make it work (old cached routes etc. from previous IPsec connections). Now I have some more clearness how the "things" work (also to my previous questions):

Port-Number and Protocol: in UTM 9.7 the settings for the port-number and protocol-type (UDP/TCP) are the same for SSL VPN Remote Access and for SSL VPN Site-To-Site. Thus if the settings are changed in one of the sections (Remote Access or Site-To-Site) the settings change for both SSL VPN types. Thus it is not possible to separate SSL VPN types (Remote Access or Site-To-Site) by different protocol or ports. The same is true for the SSL VPN IP pool. The IP pool setting is the same for both SSL VPN types. That is somewhat strange, as in other OpenVPN installations every SSL VPN instance can have a different port and protocol
-
SSL VPN tunnel IP space: UTM 9.7 pushs for the SSL VPN Site-To-Site a corresponding SSL VPN client a complete route where tunnel routing is comprised and SSL VPN tunnel IP space is given by the UTM from the selected SSL VPN pool (default SSL VPN IP pool 10.242.2.0/24). UTM takes 10.242.2.0 and other routers in the routing information will given randomly from this subnet. Thus SSL VPN Remote Access and SSL VPN Site-To-Site clients are sharing the same SSL VPN tunnel IP subnet. If an SSL VPN Site-To-Site profile is given a static virtual IP addresss an additional hop is comprised in the route pushed to the client. The virtual static IP can not be part of the pool.
For the Ubiquity EdgeOS Router I was able to compose an .opvn conform conf file from the UTM .apc file by coping over the corresponding data (certs, key, user password, cipher etc.) where user and password are set in the file "mysite.creds" referenced in the conf-file:

client
dev tun
proto udp
remote openvpn.yourserver.com 443
verify-x509-name "C=XX, L=XX, O=XX, CN=XX, emailAddress=XX"
resolv-retry infinite
remote-random
nobind
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
comp-lzo yes

hand-window 30

auth-user-pass /config/auth/openvpn-mysite/mysite.creds

route-delay 4
verb 3
reneg-sec 0
fast-io
cipher AES-128-CBC
auth SHA512

<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
[...]
-----END PRIVATE KEY-----
</key>

Best regards,

André

RE: SSL VPN : Site-to-Site SSL and Remote Access SSL VPN : Ubiquiti EdgeOS as Client

BAlfson — Thu, 09 Sep 2021 18:59:46 GMT

Hallo André,

I usually use UDP 443 for SSL VPN, both S2S and Remote Access. UDP makes the tunnels faster than using TCP. Because of Google using UDP 443, packets using that port are not blocked by any European ISP that I've heard of.
I've used TCP 1443 for SSL VPN in the past, but that was just to keep those tunnels clearly separated from any DNATs, and Web Server Protection where TCP 443 is what the world expects. In the same vein, I usually configure the User Portal on TCP 2443.
If you have distinct, non-overlapping subnets, you don't need transfer nets as described in How to tunnel between two UTMs which use the same LAN network range.
I've not had a client need to do this, so I didn't keep a record of a recommended way to solve this problem. If you search here, you'll find several answers. My preference is for IPsec using X509 authentication: How to create an IPsec Site-to-Site VPN with X509 authentication.
This is basically the same quest as 4.

Cheers - Bob
PS One of the unwritten rules practiced here is "One topic per thread" as that makes it easier for others to find answers without having to start their own thread.