Hi
I try to setup a LT2P/IpSec tunnel to my brother's Fritzbox which only talks IKEv1 (see https://mlohr.com/fritzbox-lan-2-lan-vpn-with-strongswan/).
Has anyone got something like this working? Any help welcome.
This is my configuration with IKEv1 aggressive mode, Diffie-Hellman group 14 (2048 bit MODP), and IPsec ESP in tunnel mode (no L2TP).
Fill in your own data, and set up dynamic DNS for both gateways. The tunnel will be established automatically in either direction when there is traffic for the remote subnet.
You may have to change the Fritzbox LAN to something other than 192.168.178.0/24, I am not sure about this.
# /etc/ipsec.conf
conn fritz
keyexchange=ikev1
aggressive=yes
ike=aes192-sha1-modp2048!
esp=aes192-sha1-modp2048!
leftid=@openwrt.example.org
leftauth=psk
leftsubnet=192.168.1.0/24
right=%fritz.example.org
rightauth=psk
rightsubnet=192.168.178.0/24
dpdaction=hold
auto=route
# /etc/ipsec.secrets
@openwrt.example.org @fritz.example.org : PSK "example_secret"
Use a long random PSK which can resist dictionary attacks.
# /etc/strongswan.d/local.conf
charon {
# Allow IKEv1 Aggressive Mode with pre-shared keys as responder.
i_dont_care_about_security_and_use_aggressive_mode_psk = yes
}
# /etc/config/firewall
config zone
option name fritz
option input REJECT
option output ACCEPT
option forward REJECT
option subnet 192.168.178.0/24
option extra_src '-m policy --dir in --pol ipsec --proto esp'
option extra_dest '-m policy --dir out --pol ipsec --proto esp'
option mtu_fix 1
# add a copy of the following to each non-VPN firewall zone (wan and lan)
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config forwarding
option src lan
option dest fritz
config forwarding
option src fritz
option dest lan
config rule
option name Allow-IKE-input
option src wan
option proto udp
option dest_port '500 4500'
option target ACCEPT
config rule
option name Allow-ESP-input
option src wan
option proto esp
option target ACCEPT
# fritzbox_vpn.cfg
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "openwrt";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
remotehostname = "openwrt.example.org";
localid {
fqdn = "fritz.example.org";
}
remoteid {
fqdn = "openwrt.example.org";
}
mode = phase1_mode_aggressive;
phase1ss = "dh14/aes/sha";
keytype = connkeytype_pre_shared;
key = "example_secret";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.178.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.1.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.1.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
1 Like
Thank you
I got it mostly working.
Having a repeating sequence of this
Sat Apr 27 18:09:44 2019 daemon.info : 12[IKE] sending DPD request
Sat Apr 27 18:09:44 2019 daemon.info : 12[ENC] generating INFORMATIONAL_V1 request 1706026294 [ HASH N(DPD) ]
Sat Apr 27 18:09:44 2019 daemon.info : 12[NET] sending packet: from SO.UR.CE:IP[500] to DES.TIN.ATI.ON[500] (92 bytes)
Sat Apr 27 18:09:44 2019 daemon.info : 14[NET] received packet: from DES.TIN.ATI.ON[500] to SO.UR.CE.IP[500] (92 bytes)
Sat Apr 27 18:09:44 2019 daemon.info : 14[ENC] parsed INFORMATIONAL_V1 response 1706026294 [ HASH N(DPD_ACK) ]
in my system log makes me think I got the connection running.
I also got it triggerd to start and open the connection when I try to ping an IP in the remote network. But the ping stucks and in the log I get only repeating sequences of the DPD ack.
So for me it looks like as if there is a routing problem on my side ...
In routes the route is stated as:
wan
192.168.10.0/24
WAN.GAT.EWA.Y
0
220
So this seems to be ok...
Any suggestion?
To be sure, please post the output of ipsec statusall on the OpenWrt router.
More details please. Which target host? Some packets lost, or 100% lost?
Please do not jump to conclusions, this requires some investigation.
Is the remote machine running a personal firewall? For example, Windows uses one by default. Adjust it to allow requests from non-local networks, or send pings to the LAN IP address of the Fritzbox as a workaround.
Try to find out if echo requests or replies are lost, and where:
- look at packet counters in
ipsec statusall - use a network sniffer, such as tcpdump or wireshark
Hi
thank you for your support and patience.
For ipsec statusall I get this (after trying to ping the remote Fritzbox):
root@OpenWrt:~# ipsec statusall
Status of IKE charon daemon (weakSwan 5.6.3, Linux 4.14.95, armv7l):
uptime: 21 hours, since Apr 27 20:37:27 2019
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7
loaded plugins: charon aes des sha1 md5 random nonce pubkey gmpdh hmac kernel-netlink socket-default stroke updown
Listening IP addresses:
192.168.40.1
fd42:0:0:40::1
192.168.41.1
fd42:0:0:41::1
192.168.44.1
fd42:0:0:44::1
XX.XX.XX.XXX
192.168.46.1
fd42:0:0:46::1
Connections:
barmstedt: %any...byyyyyyyyyyyyyy.myfritz.net IKEv1 Aggressive, dpddelay=30s
barmstedt: local: [sc1.mydomain.ch] uses pre-shared key authentication
barmstedt: remote: [byyyyyyyyyyyy.myfritz.net] uses pre-shared key authentication
barmstedt: child: 192.168.40.0/24 === 192.168.10.0/24 TUNNEL, dpdaction=hold
Routed Connections:
barmstedt{4}: ROUTED, TUNNEL, reqid 1
barmstedt{4}: 192.168.40.0/24 === 192.168.10.0/24
Security Associations (1 up, 0 connecting):
barmstedt[6]: ESTABLISHED 8 minutes ago, XX.XX.XX.XXX[sc1.mydomain.ch]...YY.YY.YY.YY[byyyyyyyyyyyyyyyyy.myfritz.net]
barmstedt[6]: IKEv1 SPIs: 08b0621c4b0dc4d0_i* 224aae633b98dac9_r, pre-shared key reauthentication in 2 hours
barmstedt[6]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
barmstedt{5}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c60d1611_i 3eb719e0_o
barmstedt{5}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 10668 bytes_o (127 pkts, 390s ago), rekeying in 37 minutes
barmstedt{5}: 192.168.40.0/24 === 192.168.10.0/24
I called my nephew for a Teamviewer connection to his laptop: On the Fritzbox I see the following:
So I assume the tunnel is up ..
It connected automatically after trying to ping the remote Fritzbox, so this seems to work as well.
But I can't ping the remote Fritzbox or any other device in the remote subnet. I also can't ping my OpenWrt router from the remote subnet (tried with Teamviewer session from my nephew's laptop). The Fritzbox itself respondes to ping from the remote subnet.
For me this looks like a routing problem.
I agree.
While MODP1024 might work, it is not considered secure anymore, see for example RFC 8247 or the Wikipedia article about the logjam vulnerability.
Did you try DH group 14 (MODP 2048)? Only very old Fritzboxes lack support for it. What is your Fritzbox model and FritzOS version?
There appears to be only outgoing IPsec traffic. It would be good to know whether it arrived at the destination.
Does the counter stay at 0 bytes_i when you send pings from the remote network?
From the OpenWrt router, please post the file /etc/config/firewall and the output of
ip routeip route ls table 220
(you might have to install theip-fullpackage for the latter)
Hi
The counter stays at 0 when I ping from the remote side... 
And yes, the configurationmay not be the most secure one but I think I want to solve the routing first. I don't want to do changes on two topics at the same time.
The route:
root@OpenWrt:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default XX-XX-XX-X.dcli 0.0.0.0 UG 0 0 0 eth1.2
XX.XX.XX.0 * 255.255.240.0 U 0 0 0 eth1.2
192.168.40.0 * 255.255.255.0 U 0 0 0 br-DMZ
192.168.41.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.44.0 * 255.255.255.0 U 0 0 0 eth0.44
192.168.46.0 * 255.255.255.0 U 0 0 0 wg0
The ip route ls table 220
192.168.10.0/24 via XX.XX.XX.X1 dev eth1.2 proto static src 192.168.40.1
The /etc/config/firewall
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option target 'ACCEPT'
option proto 'udp'
option name 'Allow Wireguard for Mobiles'
option src '*'
option dest_port '1195'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'udp'
option name 'Allow IPsec NAT'
option dest_port '4500'
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option name 'Allow IPsec '
option dest_port '10000'
option enabled '0'
config rule
option target 'ACCEPT'
option proto 'tcp udp'
option name 'Allow DNS (pi-hole)'
option src 'dmz'
option src_mac 'B8:27:EB:FD:42:26'
option dest 'wan'
option dest_port '53'
config rule
option name 'Deny DNS (LAN)'
option src 'lan'
option dest 'wan'
option dest_port '53'
option target 'REJECT'
config rule
option proto 'tcp udp'
option name 'Deny DNS (DMZ)'
option src 'dmz'
option dest 'wan'
option dest_port '53'
option target 'REJECT'
config rule
option proto 'udp'
option dest_port '3544'
option name 'Teredo-Filter'
option family 'ipv4'
option src '*'
option dest 'wan'
option target 'REJECT'
config rule
option proto 'tcp udp'
option dest_port '139 445'
option name 'NetBIOS-Filter'
option target 'REJECT'
option src '*'
option dest 'wan'
config defaults
option forward 'REJECT'
option syn_flood '1'
option input 'REJECT'
option output 'REJECT'
option drop_invalid '1'
config zone
option name 'lan'
option output 'ACCEPT'
option network 'lan'
option forward 'REJECT'
option input 'ACCEPT'
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wan wan6'
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config include
option path '/etc/firewall.user'
config zone
option forward 'REJECT'
option output 'ACCEPT'
option name 'voip'
option network 'VOIP'
option input 'ACCEPT'
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config zone
option forward 'REJECT'
option output 'ACCEPT'
option name 'dmz'
option network 'DMZ'
option input 'ACCEPT'
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config zone
option forward 'REJECT'
option output 'ACCEPT'
option name 'gast'
option network 'GAST'
option input 'ACCEPT'
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'voip'
option proto 'tcp udp'
option src_dport '5160'
option dest_ip '192.168.44.108'
option dest_port '5160'
option name 'sipgate'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'voip'
option proto 'udp'
option src_dport '5104-5120'
option dest_ip '192.168.44.108'
option dest_port '5104-5120'
option name 'sipgate'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'dmz'
option proto 'tcp'
option src_dport '80'
option dest_ip '192.168.40.62'
option dest_port '80'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'dmz'
option proto 'tcp'
option src_dport '443'
option dest_ip '192.168.40.62'
option dest_port '443'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'dmz'
option proto 'tcp'
option src_dport '1194'
option dest_ip '192.168.40.62'
option dest_port '1194'
config forwarding
option dest 'gast'
option src 'lan'
config forwarding
option dest 'voip'
option src 'lan'
config forwarding
option dest 'wan'
option src 'gast'
config forwarding
option dest 'wan'
option src 'lan'
config forwarding
option dest 'wan'
option src 'voip'
config forwarding
option dest 'wan'
option src 'dmz'
config forwarding
option dest 'dmz'
option src 'lan'
config zone
option name 'barmstedt'
option output 'ACCEPT'
option forward 'REJECT'
option subnet '192.168.10.0/24'
option mtu_fix '1'
option extra_src '-m policy --dir in --pol ipsec --proto esp'
option extra_dest '-m policy --dir out --pol ipsec --proto esp'
option input 'REJECT'
config forwarding
option src 'dmz'
option dest 'barmstedt'
config forwarding
option src 'barmstedt'
option dest 'dmz'
config zone
option name 'wg0'
option network 'wg0'
option output 'ACCEPT'
option forward 'REJECT'
option input 'REJECT'
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
config forwarding
option dest 'dmz'
option src 'wg0'
config forwarding
option dest 'wan'
option src 'wg0'
The routes look good to me.
Not sure if it can cause problems, but I would suggest removing the duplicate.
A side note:
Enables forwarding of traffic from dmz to all other zones. This is not the way a DMZ is usually set up. Could there be some copy-and-paste errors?
Otherwise I don't see any obvious errors.
Install tcpdump or tcpdump-mini on OpenWrt, ping again and check for incoming ESP packets on eth1.2 (ip proto 50). If ESP packets do arrive, follow their processing by the firewall (enable logging as necessary).
Hi
config zone and forwarding is as cutnpaste errror. sorry. Updated the post
I'll see if I can get a bit more information on the traffic.
I wonder what the extra_src and extra_dest option are for, especially for the none ipsec zones. How is that working?
When I created my setup, there was no official support for integrating IPsec into OpenWrt yet.
I made a configuration without a tunnel interface (VTI), just based on policies, which is still common for IPsec on Linux outside OpenWrt. The problem is that decrypted traffic coming from the ESP tunnel, and unencrypted traffic from the internet would both appear to enter the router through the wan interface. The firewall can tell them apart with the extra_src policy matches on the wan zone and on the VPN zone. A similar argument applies to extra_dest for traffic entering the tunnel or sent unencrypted to the internet.
If IPsec communication was limited to the wan interface, the --pol none match would be superfluous on zones other than wan. But since it does no obvious harm, I just set it on all non-VPN zones and don't have to consider anymore the interface on which IPsec traffic arrives or is sent.
option subnet is needed when you want to have multiple VPN tunnels and a separate firewall zone for each of them. Again, it does not hurt to set it on a single VPN zone, to prepare for extending your configuration in the future.
I did not measure the performance impact of the extraneous options, but expect it to be small.
Also see the Netfilter packet flow diagram for the order of chain traversal. IPsec traffic passes some chains twice: once before and once after encryption/decryption.
Hi
I have to thank you, it's now working. 
The problem was caused by a typo in the configuration on the FritzBox:
ipnet {
ipaddr = 192.168.40.1;
mask = 255.255.255.0;
}
is different to
ipnet {
ipaddr = 192.168.40.0;
mask = 255.255.255.0;
}
If I understand your explanation correct, it should be able to remove the
option extra_src '-m policy --dir in --pol none'
from any zone except WAN and barmstedt. I might give it a try. At the moment, I get connection from my DMZ to my brothers network.
So, last open point ... what to do if I want to extend the setup in this way:
My DMZ: 192.168.40.0/24
My LAN: 192.168.41.0/24
Remote: 192.168.10.0/24
Access should be possible like this:
My DMZ -> Remote
Remote -> My DMZ
My LAN -> Remote
Remote -| My LAN
And indeed MyLAN -> MyDMZ, MyDMZ -| MyLAN.
Any suggestion?
Yes, both extra_src and extra_dest could be removed from some zones, but I recommend to keep them. I would only remove them in case of performance problems, if at all.
In /etc/ipsec.conf, change leftsubnet from 192.168.40.0/24 to 192.168.40.0/23.
For the Fritzbox config:
phase2remoteid {
ipnet {
ipaddr = 192.168.40.0;
mask = 255.255.255.0;
}
}
change mask to 255.255.254.0.
Add this to your firewall config:
config forwarding
option src 'lan'
option dest 'barmstedt'
config forwarding
option src 'barmstedt'
option dest 'lan'
Add suitable forwardings to your firewall config. I guess you'll be able to figure these out yourself. 
Please also consider again modp2048 and phase1ss = "dh14/aes/sha".
Hi
Ok, I think I get the rest up und running myself. Need to wait until weekend to get access to remote site again.
Your assistance helped a lot. Thank you.
Please also consider again
modp2048andphase1ss = "dh14/aes/sha".
I already did 
barmstedt{11}: AES_CBC_256/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 0 bytes_o, rekeying in 12 minutes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.