Site-to-Site VPN Tutorials

The following table lists all my tutorials for site-to-site VPNs between different firewalls and routers. All of my guides are between two different products/vendors and never between the same product itself.

 AVM
FRITZ!Box
Cisco
ASA
Cisco
Router
Fortinet
FortiGate
Juniper
ScreenOS
Palo Alto
AVM
FRITZ!Box
-clickclickclickclickclick
Cisco
ASA
click--route-bsd
policy-bsd
clickroute-bsd
policy-bsd
Cisco
Router
click--clickroute-bsd
policy-bsd
route-bsd
policy-bsd
Fortinet
FortiGate
clickroute-bsd
policy-bsd
click-clickIKEv1 IPv4
IKEv1 IPv6
IKEv2 IPv6
Juniper
ScreenOS
clickclickroute-bsd
policy-bsd
clickIPv4(IPv6)click
Palo Altoclickroute-bsd
policy-bsd
route-bsd
policy-bsd
IKEv1 IPv4
IKEv1 IPv6
IKEv2 IPv6
clickIPv4(IPv6)

Other S2S VPN Articles on my Blog

VPN Speedtests

[DE] Articles covering AVM FRITZ!Box

External Links

Featured image: “Röhre // Pipe” by Frank Lindecke is licensed under CC BY-ND 2.0.

16 thoughts on “Site-to-Site VPN Tutorials

  1. Would you be able to tell me how to do the site to site VPN from a Juniper to a Cisco ASA without a static IP on the Juniper side?

  2. If you’d like to add Mikrotik to this list, let me know. Would be happy to go over configs with you.

  3. Thanks for providing these informative lists for site to site VPNs between different firewalls and routers. Somethings needful I got on web.

  4. Hi,
    I would like to know how to configure IP Sec Site-to-site VPN between Fortigate 60D and Sonicwall Firewall routers.
    Regards,
    Ruwan

  5. hallo
    ich habe im Moment das Problem das ich in eine OPNsense eine VPN Verbindung zu einer Fritzbox herstellen will ,nun meine frage gibt es dafür eine aktuelle Anleitung oder kann mit da jemand helfen

  6. Hello, for me it will be helpful to get infos for a fritzbox 07.21 and a Sophos XG home edition V 18.0.4 site to site connection. both Drives have a DynDNS address.
    I try from the Fritz!Box the only possibility over the WEb-Gui setup for a company connect. for Remote site gateway I use xxxx.xxxx.@zzz.co and for the Fritzbox own the xxx.zzzz.@fritzbox.net

  7. This site is a fantastic resource for working out how to set up IPsec tunnels.

    Maybe this will be useful for somebody after spending hours trying out different combinations and going from a working Strongswan behind an ancient decrepit D-Link router to a just acquired Fritzbox 7490, to connect to a remote (end of the line) Cisco RV220W.

    On the Cisco RV220W
    —————————–
    IKE Policy:
    Main FritzBox_external_name_.inet2.org RV220W_external_name.inet2.org AES-256 SHA-1 Group 5 (1536bit )

    For extended authentication:
    XAUTH Type – Edge Device
    Authentication Type – User Database

    Entries for user and password must be entered on VPN Users page via “add” function. Do not try on the VPN Advanced User page to use Authentication Type – IPsec host and enter user and password in the boxes on that page as this does not provide a working XAUTH login.

    VPN Policy Table:
    Auto Policy RV220W_local_network _IP / 255.255.255.0 Fritzbox_local_network _IP / 255.255.255.0 SHA-1 AES-256 Group 5 (1536bit)

    For FritzBox vpncfg
    —————————

    The following settings must be used to get a working IPsec tunnel.

    phase1ss = “dh5/aes/sha”;
    phase2ss = “esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs”;

    Attempts at changing the fields to try for better compatiblity (other than use of dh5) resulted in no connection being attempted by the FritzBox, as FritzOS apparently only supports a limited set of valid combinations.

    The RV220W will complain with a warning that Peer’s Proposal (from FritzBox) “authtype=hmac-sha2-512” does not match with Local Proposal (on RV220W) “authtype=hmac-sha” cannot be avoided.

    Changing the authtype (Integrity Algorithm in the VPN Policy Table) to SHA2-512 results in the IPsec tunnel being established successfully without the warning, but the tunnel does NOT work even though it shown as up on both the FritzBox and the RV220W. Pinging hosts on the other local network on other side of the tunnel result in 100% packet loss when tested from both networks. This is possibly due to either the bad software (even the last firmware ever issued) for the RV220W, or that the low specification hardware (CPU and/or memory) is not sufficient to cope with the much heavier load of SHA2-512. If you have ever read the Cisco Forums for RV220W problems (and related RV180W) you would know that this product that had such great potential at the time of release was forever seriously flawed (especially with IPsec frustrations).

Leave a Reply

Your email address will not be published. Required fields are marked *