Project

General

Profile

Issue #219

Fritzbox <> Strongswan Gateway

Added by ivo neer about 8 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Affected version:
Resolution:
No feedback

Description

Hello again
After successfully setting up the IPSEC Tunnel between iPhone and strongSwan, I am now stumbling with a second requirement.
I try to get the following scenario working:
[internet] <-> [strongSwan gateway] <===>IPSEC TUNNEL<===> [Fritzbox] <-> [local network, 192.168.177.0]

The FritzBox creates the ipsec-tunnel with strongSwan. The tunnel is already beeing set up correctly, but there seems nothing to be routed thru the tunnel.
Neither calls from the strongSwan-Gateway to a http-server in the 192.168.177.0 network, nor calls from the 192.168.177.0 network to the strongSwan-gateway.

Now my questions:
Which of your sample-configs should I use as a pattern to define the ipsec.conf for this connection?
In this scenario, which is the left side? left from strongSwan, correct?
Is there something missing in the ipsec.conf? Please see my config below.

Kind regards
Ivo Neer

conn test
leftid=@vpn.thegateway.net (the strongswan-gateway)
left=%defaultroute
leftsubnet=0.0.0.0/0
leftfirewall=yes
ike=aes256-sha1-modp1024
esp=aes256-sha1-modp1024
right=xyz.dyndns.org (the fritzbox dyndns ip)
rightid=@yxz.dyndns.org
rightsubnet=192.168.177.0/24
authby=secret
auto=add

History

#1 Updated by Tobias Brunner about 8 years ago

  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner
  • Target version deleted (5.0.1)

In this scenario, which is the left side? left from strongSwan, correct?

The convention is this:

Left = Local (strongSwan in your case)
Right = Remote (your FRITZ!Box)

What is your intention here exactly. Is the main point that the gateway reaches hosts in the 192.168.177.0/24 subnet, or that the hosts in that subnet reach the gateway? Should hosts in that subnet access the Internet via the gateway?
Also, is the FRITZ!Box the default gateway of the 192.168.177.0/24 subnet?

#2 Updated by Uwe Dormann over 7 years ago

I try getting a Net-2-Net tunnel between strongswan 5 and Fritzbox re-established which I used for quite a while running strongswan 4.6.4. It failed using strongswan 5.0.2, but since 5.0.3 it looks much better. From what I could see, #295 and #301 fixed some of the log errors I could see on 5.0.2.

However, establishing the tunnel still has some issues.

My config:

conn RemoteOffice
        aggressive=yes
        left=ipfire.dyndns.org
        leftsubnet=192.168.42.0/24
        leftallowany=yes
        leftfirewall=yes
        lefthostaccess=yes
        right=remoteoffice.dyndns.org
        rightsubnet=192.168.17.0/24
        rightallowany=yes
        leftid="@ipfire.dyndns.org" 
        rightid="@remoteoffice.dyndns.org" 
        ike=aes256-sha1-modp1024
        esp=aes256-sha1-modp1024
        keyexchange=ikev1
        ikelifetime=1h
        keylife=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=none
        authby=secret
        auto=route

Note: I also tried aggressive=no but with yes the test results are more reliable

My test procedure:
  1. /etc/init.d/ipsec restart
  2. ping 192.168.17.1 (No response)
  3. ipsec up RemoteOffice
  4. ping 192.168.17.1 (OK)
  5. jump 1

In 1-2 out of 10 cases ping already works immediately after the restart at 1). But most of the time it requires the "ipsec up RemoteOffice" at 3) before it succeeds.

The conection itself already looks like being established after the ipsec restart at 1).

Routed Connections:
RemoteOffice{1}:  ROUTED, TUNNEL
RemoteOffice{1}:   192.168.42.0/24 === 192.168.17.0/24
Security Associations (1 up, 0 connecting):
RemoteOffice[2]: ESTABLISHED 6 minutes ago, 84.159.122.97[ipfire.dyndns.org]...91.39.87.240[remoteoffice.dyndns.org]
RemoteOffice{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c8e0eee1_i 6b76c55e_o
RemoteOffice{1}:   192.168.42.0/24 === 192.168.17.0/24
RemoteOffice{2}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c7b4c8e6_i c0ccbd35_o
RemoteOffice{2}:   192.168.42.0/24 === 192.168.17.0/24 

and ip xfrm policy

src 192.168.17.0/24 dst 192.168.42.0/24
   dir fwd priority 1859
   tmpl src 91.39.87.240 dst 84.159.122.97
      proto esp reqid 2 mode tunnel
src 192.168.17.0/24 dst 192.168.42.0/24
   dir in priority 1859
   tmpl src 91.39.87.240 dst 84.159.122.97
      proto esp reqid 2 mode tunnel
src 192.168.42.0/24 dst 192.168.17.0/24
   dir out priority 1859
   tmpl src 84.159.122.97 dst 91.39.87.240
      proto esp reqid 2 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
   socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
   socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
   socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
   socket out priority 0
src ::/0 dst ::/0
   socket in priority 0
src ::/0 dst ::/0
   socket out priority 0
src ::/0 dst ::/0
   socket in priority 0
src ::/0 dst ::/0
   socket out priority 0 

Any idea why the tunnel looks like being established but isn't unless manual brought up again. ? Any hint how to debug further ?

#3 Updated by ivo neer about 7 years ago

Hello

Almost a whole year is past since I put my project on ice.
Thanks for your reply, I totally missed it last year.

You asked: "What is your intention here exactly?"

My hosts in the subnet (192.168.177.0) should reach the gateway. The main target is to tunnel all the internet traffic to the gateway. Yes, the FRITZ!Box is the default gateway of the 192.168.177.0/24 subnet. Tunnel will be set up by the FRITZ!Box.

[internet] <-- [strongSwan gateway] <===IPSEC TUNNEL<=== [FRITZ!Box, default Gateway] <-- [local network, 192.168.177.0]

To me, it seems like it is a FRITZ!Box routing issue.
Am I guessing right?

Kind regards
Ivo Neer

#4 Updated by Tobias Brunner about 7 years ago

  • Tracker changed from Feature to Issue

Ok, if you have the tunnel established, as described by the config you posted back then, all traffic from the 192.168.177.0/24 subnet should be sent to the strongSwan gateway (you could perhaps try to verify that with tcpdump or a look at the packet counters in ip -s xfrm state).
The only thing you have to do then is to NAT traffic from 192.168.177.0/24 to the public IP of the strongSwan gateway (for the mentioned setup for iOS devices you probably already have some NAT rules in place, right?).

#5 Updated by Tobias Brunner about 6 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No feedback

Also available in: Atom PDF