IPSEC between Zentyal and Sonicwall not working

[rahul_dhakan]

Firewall rules configured from GUI on Zentyal:
internal networks to Zentyal -> Allow Any Any
internal networks -> Allow Any Any
external networks to Zentyal -> Allow Any IPSEC
Traffic coming out from Zentyal -> Allow Any Any

Do I need to allow anything more from external to internal?

[jbahillo]

Are you sure that both Zentyal and Sonicwall have Public IP addresses?. Zentyal IPSEC module does not support at this moment NATted tunnels for IPSEC.

[rahul_dhakan]

Yup both Zentyal and sonicwall have public ip address and I can see tunnel up in at both the side.

[christian]

what is not clear to me is the current status.
You have added FW rules and show new log capture where there is no more dropped packets except ICMP (BTW do you accept ICMP ?) and remote desktop.
Does it mean that is works for other protocols now ?

[rahul_dhakan]

Current status is same as previous. It does not allow any protocol however I have allowed Any Any so it should allow TCP/ICMP any but it doesn't. I show you ICMP and remote desktop only as I was testing only for them.

[christian]

Looking at some screen copy in documentation, it looks like there is no place for rules applied to "internet to intranet"
Is there something I missed or do you confirm 3.x interface is built this way ?

[rahul_dhakan]

We can apply manual rules by putting iptables rules in /etc/zentyal/hooks/firewall.postservice and I added rules accordingly but it does not work. I have called bye to Zentyal for now and configured PfSense yesterday with same rule to Sonicwall and it works perfectly. I appreciate your help and response.

[ugly_joe]

i have exactly same problem. Its pfsense on other side, so its zentyal firewall/routing bug.

[vargax]

Hi,

After a lot of searching and debugging I could setup the IPSec LAN to LAN VPN in Zentyal 3.3. You have to create a Firewall postservice script in /etc/zentyal/hooks allowing incoming connections from the remote subnet:

Code: [Select]

cd /etc/zentyal/hooks
cp template.postservice firewall.postservice
nano firewall.postservice

At the end of the file, before exit 0 add "iptables -A ffwdrules -s <remote_subnet> -j ACCEPT" for example:

Code: [Select]

# Hook scripts need to be executable by root (note that examples are not).

iptables -A ffwdrules -s 192.168.9.0/24 -j ACCEPT
iptables -A ffwdrules -s 192.168.10.0/24 -j ACCEPT
iptables -A ffwdrules -s 192.168.12.0/24 -j ACCEPT

exit 0

In my case the local subnet is 192.168.11.0/24 and I have 3 remote subnets: 192.168.9.0/24 192.168.10.0/24 192.168.12.0/24, so I have 3 IPsec LAN to LAN tunnels.

References:
http://wiki.openwrt.org/doc/howto/netfilter
http://trac.zentyal.org/ticket/7881

[allan]

Thank you Vargax, we've been having the exact same issue and your solution worked perfectly!

[vargax]

Actually I found a better solution, making it to work like in Zentyal 2.0...

You have to ssh to the server, then:

Code: [Select]

sudo su
nano /etc/zentyal/firewall.conf

Look for the last lines and uncomment it:

Code: [Select]

# Uncomment the following to show the from External to Internal section
show_ext_to_int_rules = yes

# Uncomment the following to show the Rules added by Zentyal services
show_service_rules = yes

Now in the firewall module you would find two new sections (you may be need to reboot your server):
- From external to internal networks
- Zentyal services

In the External to Internal networks you can create rules to allow traffic between IPsec subnets:



Just create a new Network Object for your subnets:



And then create a new rule in External to Internal Networks allowing traffic from subnets to subnets:



You will note that now you can access hosts in the subnets but you can not access the servers through its private IPs:

- Server A can not access hosts in subnet B
- Server B can not access hosts in subnet A
- Server A can not access services in Server B through B's private ip
- Server B can not access services in Server A through A's private ip

To solve this you have to edit /etc/ipsec.conf and add the proper leftsourceip and rightsourceip parameters in each connection:

Code: [Select]

# VPN: l222 (ipsec): 11.11.11.11 <=> 10.10.10.10
conn l222
        left=11.11.11.11
        right=10.10.10.10
        rekey=yes
        keyingtries=0
        leftsubnet=192.168.11.0/24
        leftsourceip=192.168.11.1 # !!!!!!!!!!!!!!!!!!!
        rightsubnet=192.168.10.0/24
        rightsourceip=192.168.10.1 # !!!!!!!!!!!!!!!!!!!
        pfs=yes
        auth=esp
        keyexchange=ike
        ike=3des-md5
        ikelifetime=28800s
        esp=3des-md5;modp1024
        keylife=3600s
        authby=secret
        auto=start

# VPN: hayuelo (ipsec): 11.11.11.11 <=> 9.9.9.9
conn hayuelo
        left=11.11.11.11
        right=9.9.9.9
        rekey=yes
        keyingtries=0
        leftsubnet=192.168.11.0/24
        leftsourceip=192.168.11.1 # !!!!!!!!!!!!!!!!!!!
        rightsubnet=192.168.9.0/24
        rightsourceip=192.198.9.1 # !!!!!!!!!!!!!!!!!!!
        pfs=yes
        auth=esp
        keyexchange=ike
        ike=3des-md5
        ikelifetime=28800s
        esp=3des-md5;modp1024
        keylife=3600s
        authby=secret
        auto=start

After this you need to restart the ipsec service:

Code: [Select]

service ipsec restart

Unfortunately this changes are lost when you reboot the server or add a new IPsec connection... Right now my solution is to have a copy of the ipsec.conf file and restore it after each reboot...

After adjust ipsec.conf:

Code: [Select]

cp /etc/ipsec.conf /root/ipsec.conf
nano /etc/zentyal/hooks/ipsec.postservice

And put inside:

Code: [Select]

#!/bin/sh
service ipsec stop
cp /root/ipsec.conf /etc/ipsec.conf
service ipsec start

exit 0

Then set the correct mod:

Code: [Select]

chmod --reference=/etc/zentyal/hooks/template.postsetconf /etc/zentyal/hooks/ipsec.postsetconf

Off course you have to adjust your backup file (/root/ipsec.conf) after each config change you made through the web interface.

This bug was reported here: https://tracker.zentyal.org/issues/48 and it persist in Zentyal 3.4

Sources:
http://serverfault.com/questions/503864/openswan-tunnel-up-but-works-only-in-one-direction
https://wiki.debian.org/HowTo/openswan
https://lists.openswan.org/pipermail/users/2005-December/007589.html