Need configure OW as VPN Client to Zyxel GIGA III (IPSEC).
OW look like roadwarrior.
So that type of strongswan need?
And example of config, because mobile devices connect to Zyxel via shared key, login, pass. No any phase 1,2.
Information about phases find on off.site:
Please only open one thread on a topic.
https://forum.openwrt.org/t/router-as-client-l2tp-ipsec/29929
2 Likes
You might want to mention IPsec/IKE in the subject (click edit).
Which version of the IKE protocol does the Zyxel GIGA III use: IKEv1 (also called ISAKMP) or IKEv2?
The strongSwan wiki has config examples for both IKEv1 and IKEv2. Search for rw and psk there (rw: road warrior, psk: pre-shared key).
Phase 1 and 2 are an IKEv1 concept; IKEv2 works in a different way.
Login by username and password likely means Xauth (IKEv1) or EAP (IKEv2).
Click on a single test case, for example rw-psk-ipv4. There you find the config, you can ignore the test output. Repeat as needed with other tests to see more examples.
They poor for me doc, not usable :
[I] Feb 1 12:46:06 ipsec: 13[IKE] 47.211.133.56 is initiating an IKE_SA
[I] Feb 1 12:46:06 ipsec: 13[CFG] received proposals: IKE:AES_CBC=128/AES_CBC=192/AES_CBC=256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/HMAC_SHA1_96/PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_SHA1/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
[I] Feb 1 12:46:06 ipsec: 13[CFG] configured proposals: IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_768, IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_768, IKE:DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_768, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_768, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_768, IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_768, IKE:AES_CBC=128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_768, IKE:AES_CBC=128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_768, IKE:AES_CBC=128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_768
[I] Feb 1 12:46:06 ipsec: 13[IKE] remote host is behind NAT
[I] Feb 1 12:46:06 ipsec: 13[IKE] received proposals inacceptable
So client WO can't work as server request.
Temporary on server site update config(I no need strong security, only tunnel)
But now can't find how to forward traffic from client to tunnel (not all, part of network on server site)
The configuration needs some adjustment.
This logfile was produced by the responder, I assume this is the Zyxel GIGA III.
The initiator uses protocol version IKEv2.
The initiator (OpenWrt client) proposes a set of algorithms which looks good to me.
The responder is configured to accept these proposals. Some of them use a block cipher that is very insecure (DES_CBC) and should be removed from the responder configuration.
Instead of MODP_768, a larger Diffie-Hellmann group should be used. I recommend MODP_2048 or higher, or elliptic curve DH, for example curve25519.
This is not an error, just informational.
This is where the connection fails.
The reason is most likely the mismatch in the Diffie-Hellman group size (MODP_768 vs. MODP_2048 and up).
Please don't give up yet.
Remove any IKE and ESP proposals from the responder configuration and let strongSwan use its built-in defaults.
To get more help, post your configs and logfiles here.
StrongSwan automatically installs the routes and policies according to its configuration.
Do the relevant left-/rightsubnet definitions include the network on server site in question?
Do the machines in this network have a route back to the VPN gateway?
Does your client router have NAT enabled on its WAN interface?
Please show your client and server configs, for IPsec and firewall.
Hello, I need config for situation as on picture.
Tunnel work, I can see in logs what OWRT tunnel link up, connected.
Thank you for this diagram.
Is User --> PC the connection that is broken?
For both VPN server and OpenWrt, please show us:
-
/etc/config/network(blank out any secrets) /etc/config/firewall/etc/ipsec.conf- the output of the command
ipsec statusallwhen the VPN tunnel is up
We can then suggest improvements based on your configuration.
Client side
Statusall:
Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.14.63, mips):
uptime: 19 minutes, since Feb 06 18:34:08 2019
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pgp dnskey sshkey pem fips-prf gmp xcbc hmac attr kernel-netlink resolve socket-default connmark stroke updown xauth-generic
Listening IP addresses:
192.168.2.1
fd57:ea51:6153::1
192.168.43.25
Connections:
Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.14.63, mips):
uptime: 19 minutes, since Feb 06 18:34:08 2019
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pgp dnskey sshkey pem fips-prf gmp xcbc hmac attr kernel-netlink resolve socket-default connmark stroke updown xauth-generic
Listening IP addresses:
192.168.2.1
fd57:ea51:6153::1
192.168.43.25
Connections:
PC_tunnel: %any...70.100.100.100 IKEv2, dpddelay=90s
PC_tunnel: local: uses pre-shared key authentication
PC_tunnel: remote: uses pre-shared key authentication
PC_tunnel: child: 192.168.221.33/32 === 192.168.222.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
PC_tunnel[1]: ESTABLISHED 19 minutes ago, 192.168.43.25[192.168.43.25]...70.100.100.100[70.100.100.100]
PC_tunnel[1]: IKEv2 SPIs: a2b29e7ecbc633f4_i* bb00cad66a4f4b04_r, pre-shared key reauthentication in 31 minutes
PC_tunnel[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_3072
PC_tunnel{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6381c83_i c270fcd8_o
PC_tunnel{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 24 minutes
PC_tunnel{1}: 192.168.221.33/32 === 192.168.222.0/24
IPSEC.conf
ipsec.conf - strongSwan IPsec configuration file
basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
Add connections here.
Sample VPN connections
conn PC_tunnel
authby=secret
auto=start
closeaction=restart
dpddelay=90
dpdaction=restart
keyexchange=ikev2
keyingtries=%forever
fragmentation=yes
left=%defaultroute
leftsubnet=192.168.221.33/32
right=70.100.100.100
rightid=%any
rightsubnet=192.168.222.0/24
Network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd57:ea51:6153::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.2.1'
config device 'lan_dev'
option name 'eth0.1'
option macaddr '80:1f:02:21:0d:bb'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_dev'
option name 'eth0.2'
option macaddr '80:1f:02:21:0d:b8'
config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 9t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0 9t'
config interface 'wifiwan'
option proto 'dhcp'
firewall
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
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 wifiwan'
config forwarding
option src 'lan'
option dest 'wan'
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 name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
OpenWrt uses the private IP address 192.168.43.25. Could you get a public IP address (IPv4 or IPv6) for the OpenWrt router? This is optional, but it allows a more stable configuration. Even a single dynamic address would be an improvement.
The tunnel is up, but no traffic has been flowing yet. The traffic selectors 192.168.221.33/32 === 192.168.222.0/24 and the gateway address do not match your network diagram. Please fix the diagram or the configuration. Below I will assume that the diagram is correct.
On OpenWrt:
- Change the traffic selectors and gateway address in ipsec.conf:
Adjust the subnet masksleftsubnet=192.168.1.100/32 right=70.1.23.45 rightsubnet=10.10.10.0/24/24and/32as needed. - Make sure that NAT is not applied to tunneled traffic. For a simple solution, add the following line to
/etc/firewall.user(untested):iptables -t nat -A postrouting_wan_rule -m policy --dir out --pol ipsec --proto esp -j ACCEPT - Update: Allow incoming IPsec-protected traffic to be forwarded:
More featureful solutions could be imagined too, for example a separate VPN zone in the OpenWrt firewall.iptables -A forwarding_rule -m policy --dir in --pol ipsec --proto esp -j ACCEPT
On the VPN Server:
- Change the traffic selectors to match OpenWrt.
- Disable Diffie-Hellman group 1 (768 bit), it is insecure.
- Disable DES, it is insecure.
- Disable 3DES (optional).
In your diagram, User is labelled with 10.10.10.0. Is that an IP address or a subnet?
- In case of a subnet, it is missing the subnet mask.
- In case of an IP address: Don't assign the
.0address to a host (assuming the subnet mask is/24).
Furthermore, there are IP addresses 192.168.222.0 and 192.168.100.100. What is their purpose?
The traffic selectors specify the IP addresses of the hosts that want to communicate across the tunnel. A VPN gateway does not need to have an IP address from the traffic selector range unless you want it to take part in the tunneled communication.
I don't use uci or LuCI to set up strongSwan, maybe someone else can answer this.