EFW Support

Hi everybody,

I'm using OpenVPN with digital certificates (option "X.509" in OpenVPN Server - Advanced) on Endian CE 2.4 to connect 2 remote LANs through internet.

The VPN connection comes up without problems and is very stable, and from each site I can ping the EFW of the other side (I can ping its Green Interface IP): I can ping it from the LAN PC, and not only from the EFW of the remote site. Forgot to mention that I've already created 2 tunnels, in both directions.

But when a PC in a site (LAN) try to ping a PC on the other site, the first packets obtain a "reply to" and everything goes well, but the following ones obtain a "destination unreachable" from the local EFW...
The thing even more unbelievable is that if a run a "continuous ping" (ping -t), from time to time I obtain again a "reply to" from the remote site.

It seems like Endian VPN tunnel drops the packets: it drops more or less 70-80% of the traffic...

One of the two EFW is running on a VMware ESXi virtual machine, but I do not think that this is the origin of the strange behaviour...

Did someone else experience this behaviour and find a solution?

Thank you very much,
Luca

Hi,

You have to create this connection only.


Server --------> Gw2Gw Client
                    ---> Gw2Gw Client
                    ---> Gw2Gw Client

and put this in your /etc/sudoers

openvpn ALL=NOPASSWD: /usr/local/bin/setdnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/remoteroute.py

Here are the outputs of the "route -n" and "cat /etc/sudoers | grep openvpn" for both EFW.

root@fw01:~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
78.4.160.48     0.0.0.0         255.255.255.248 U     0      0        0 eth1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 tap2
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
0.0.0.0         78.4.160.49     0.0.0.0         UG    0      0        0 eth1
root@fw01:~ # cat /etc/sudoers | grep 'openvpn'
nobody  ALL=NOPASSWD: /usr/bin/openvpn-user
nobody  ALL=NOPASSWD: /usr/local/bin/restartopenvpn.py
openvpn  ALL=NOPASSWD: /usr/local/bin/updatednsmasq.py
nobody  ALL=NOPASSWD: /usr/local/bin/restartopenvpnclients.py
openvpn  ALL=NOPASSWD: /usr/local/bin/remoteroute.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setsnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setpolicyrouting.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setrouting.py
nobody  ALL=NOPASSWD: /etc/init.d/openvpnclient
openvpn  ALL=NOPASSWD: /usr/local/bin/setdnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setvpnfw.py
root@fw01:~ #

root@efw-1283440485:~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
93.64.140.112   0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 tap1
0.0.0.0         93.64.140.113   0.0.0.0         UG    0      0        0 eth1
root@efw-1283440485:~ # cat /etc/sudoers | grep 'openvpn'
nobody  ALL=NOPASSWD: /usr/bin/openvpn-user
nobody  ALL=NOPASSWD: /usr/local/bin/restartopenvpnclients.py
nobody  ALL=NOPASSWD: /etc/init.d/openvpnclient
nobody  ALL=NOPASSWD: /usr/local/bin/restartopenvpn.py
openvpn  ALL=NOPASSWD: /usr/local/bin/updatednsmasq.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setsnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setvpnfw.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setrouting.py
openvpn  ALL=NOPASSWD: /usr/local/bin/setpolicyrouting.py
root@efw-1283440485:~ #

I see that the last one have not "openvpn" (but "nobody") on the "setdnat" and "remoteroute" lines: I'll put in it "openvpn" and I'll make you know.

Thank you for your help,
Luca

Here am I.

I have settled the correct rights in /etc/sudoers, but the problem of packet loss remains...

I have also configured some "source nat" and "vpn firewall" rules (see the attachements), but the problem remains...

I finally tried to use a single VPN connection (instead of two, in both directions), but in this way I cannot neither ping the remote EFW green interface (with both VPN connections I can ping without problems the remote EFW Green interface).

Luca

Hi,


Please isolate your ISP connection first, maybe there's a problem.

Hi all,

I've finally tried from the ground up the "single VPN connection" (and rebooted both EFW) and in fact... it's WORKING now :) and there is NO MORE packets loss.  :D

There is, however, a last problem. Everything is working right but only in one direction (let's say from the EFW acting as "OpenVPN client" to the EFW acting as "OpenVPN server"), but I would need a bidirectional link.
At the moment only the LAN PCs behind the "OpenVPN client" can connect to the LAN PCs behind the "OpenVPN Server".

I've also tried to "ping" the LAN behind the "OpenVPN client" from an SSH session on the "OpenVPN server", but there is NO ROUTE to the remote LAN. I cannot "ping" the remote EFW acting as "OpenVPN client" itself.

How is it possible to iobtain a bidirectional tunnel???

Thank you very much,
Luca

put this in your sudoers



openvpn ALL=NOPASSWD: /usr/local/bin/setdnat.py
openvpn  ALL=NOPASSWD: /usr/local/bin/remoteroute.py

Dear Leonil,

"/etc/sudoers" at both EFW is already configured as you suggested...

Is there something else that I could check?

In my opinion there is a preceding difficulty: executing an "ifconfig -a" at the remote EFW acting as "OpenVPN client" I see the "tap1" interface associated with the VPN tunnel configured, but executing the same command at the loal EFW acting as "OpenVPN server" I see NO such an interface. Not being present such an interface, it is perfectly comprehensible that the "OpenVPN server" does not know where to send packets whose destination is the remote LAN... Isn't it?  ;)

Luca

Hi all,

everything solved and perfectly working now: here is the solution:
http://bugs.endian.com/view.php?id=3145

Your suggestion of configuring a SINGLE vpn connection is the right one: a double tunnel (one from EFW client to the EFW server and another one in the opposite direction) creates routing problems!

Thank you everyone (Leonil in particular) for your help.

In attachment a little howto about a Gw2Gw configuration with digital certificates, hoping that it could be of some help for someone.

Luca