- This topic is empty.
June 11, 2017 at 9:23 pm #44820
I bought a Raspberry Pi 3 to replace my x86 system running ZS (3.7.1).
As I have a bunch of config, bonded VPNs, 4 WAN connections, SSL cert, port forwarding etc, I don’t want to have to reconfigure everything manually.
I made a “backup without logs” from my x86 system, and I “restore profile” to the Raspberry Pi (running 3.7.1A). This mostly worked, but I had to remove and recreate the WAN interfaces since they were bound to a NIC which didn’t exist on the Pi etc. I also VLAN tagged the 5 interfaces (LAN + 4x WAN) so I can use the single ethernet port on the Pi, and this is plugged into a Linksys AP with matching VLAN tags.
DHCP also wasn’t running until I disabled and re-enabled it, for it to realise the LAN subnet was now a VLAN tagged interface.
The main weird issue I can’t seem to resolve is with the VPNs. Initially they wouldn’t connect from the Pi as I had configured them on the x86 system to use padlock engine (built into the CPU of the AMD in the x86, not in the Pi..) so I disabled this, and now the VPNs connect, and traffic will pass (but the interfaces and the bond interface aren’t/weren’t working properly, and I had to manually bring up the VPN00 interfaces, and ifenslave them into the BOND00 interface), but ZS continues to show them as stuck “connecting to remote peer”.
This also seems to interfere with the bonding, as the wrong/non primary VPN of the bond interface is being used, and traffic seems to stop and restart across the VPN constantly. Running a pcap I can see ARP requests being sent from ZS, but not arriving on the other end’s tap interface, and then all of a sudden it will start working again.
Is there some file(s) which is different between these platforms I have mucked up by bringing over the profile from a different platform? Is the version difference between 3.7.1 and 3.7.1A part of the problem? Is there something I can fix, or should I just cut my losses and delete the profiles and start all over again and configure it manually rather than trying to import my config from the x86 platform to the Pi platform?June 11, 2017 at 10:08 pm #54476
I realised I could connect the LAN interface using the WiFi interface on the Pi, rather than VLAN tagging the single port and just use it for my 4 WAN connections (in /29 subnets), in case that was the problem, since it was the only real difference from the x86 system.
I rebooted into the original profile, and I configured things that way from scratch, rather than trying to import the config.
I setup the net balancer and the VPNs exactly the same, exporting and importing the X509 certs etc, and yet the VPN still gets stuck on “connecting to peer”, even though it comes up, and the log file has “Initialization Sequence Completed” at the end.
Now I’m confused as to why it’s not working out that the VPN has connected.June 12, 2017 at 2:23 pm #54477
So I continued fiddling with no success. Doing a sanity check, I moved the x86 box to another LAN IP, and WAN IPs, and changed the VPN config to exactly match the Raspberry Pi.. The VPNs connect with no issues.
I think there’s something funny/broken with the VPN LAN to LAN support in 3.7.1AJune 30, 2017 at 6:18 am #54478
I’ve just got back to Canada from a 2 week vacation to Australia and have started looking at this again. With exactly the same config on both systems, only one will have the VPN connect. There must be something different..
I looked in the log files on both systems to compare, after connecting, and attempting to compare. I notice that the OpenVPN versions are very different.
The x86 system which works is running:
OpenVPN 2.4.0 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 4 2017 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.03
The RPi is running:
OpenVPN 2.3.10 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jan 29 2016 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09
My server/remote system is running:
OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec 1 2014
So I’m beginning to suspect an issue with 2.3.10 armv7l-unknown-linux-gnueabihf.July 6, 2017 at 6:18 pm #54479
Replying to myself..
I’m now thinking the issue is with the scripts that surround bringing the VPN up.
When I check the log from starting the VPN, it says that interface VPN00 is down.
I logged in to get a shell, and I can’t even run a tcpdump on the interface as “that interface is not up”. When I manually bring it up “ifconfig VPN00 up”, then I can tcpdump and I see the traffic, and it will work. If I restart the VPN it will take the interface down, but not bring it back up again.
I’m wondering if my attempt to restore the profile from the x86 system may have mucked with some scripts causing a mismatch between the Pi image and the x86 install?July 18, 2017 at 6:55 pm #54480
Continuing to talk to myself..
I tried re-imaging the SD card’s non profile partitions, and this made no difference.
For now I have gone back to the x86 system as my router.
I have ordered an Orange Pi and will try again there.
- You must be logged in to reply to this topic.