Firmware 7.2 (I just upgraded one to 8.0 - no change)
ISPs:
** Loc A: comcast
** Loc B: AT&T Uverse
I tried my PepVPN setup once connecting both to the same router (a 3rd one), and it worked fine. Now the two Pepwave’s are >200km away from each other.
Comcast directly exposes the router to the internet. I am also running a server at that location and can connect to it from outside without problem.
AT&T Uverse supplies a router that is put in “DMZ-Plus” mode, which supposedly forwards all ports to the Pepwave. The pepwave shows the external IP address under the WAN Status tab.
Both IPs block only the usual ports (25, …), not the ones PepVPN uses by default (I have not changed those).
I would expect at least Loc B to be able to connect to Loc A (the webserver in Loc A is accessible e.g. from Loc B through the the internet, not PepVPN), but apparently that’s not the case.
How do I troubleshoot?
In the log I only once found a terse message that PepVPN is not working (I figured that much …).
DMZ isnt secure and will leave your unit vulnerable to attacks from the outside.
It is better to forward the needed ports for Pepvpn from the AT&T modem towards the Peplink.
To check if the needed ports are open and responding, setup Pepvpn on the unit like you already did. Then use a portscanning tool to check if the ports are open and reachable on the WAN address. You can do this on both sides to test. Port will only show as open when there is a profile for pepvpn setup as the peplink will then start listening over those ports.
Also make sure you wont have any networking conflicts (same subnets on both sides).
To see more clearly what is happening go to:
Status>Speedfusion> (check the disconnected profiles checkbox)
Now you can see in the status what is happening. Look below to find the issue your stuck at.
Before deployment
Ensure either site has public IP.
Ensure port Tcp32015 and Udp4500 are open.
Please ensure WAN IPs for both units are reachable. You my go System > Ping to confirm this.
Starting… - VPN engine knows about this profile, and either waiting for client to connect, or trying to connect to the remote peer.
Authenticating… - You might not be able to see this state because it should normally be short-lived. However, if you are stuck at this state, that means you have some authentication error, check PSK/X.509/ Remote ID setting settings. TCP 32015 is used on this state.
Creating Tunnel… - This is after authentication is successful. VPN tunnel is creating in this stage. If you are stuck at this state, that means no tunnels are connected (L3 speedfusion) or there is something wrong with bridging the VPN interface (for Layer 2 Speedfusion).
Updating Routes… - (Layer 3 only) Once one or more tunnel is health check OK, we can proceeds to exchange routes. If you are stuck at this state, you most likely need to first check for route conflicts between peers, including WAN IPs.
I’ve changed the setup in Location B to use port forwarding instead of DMZ. As a consequence the router now gets a local IP (no longer WAN IP). I’m also forwarding port 80 for testing.
Port scanning: I am using an app (iNetTools) on a phone with wifi disabled to be sure to be testing from the WAN.
ping of Location A works
ping of Location B works after I disabled the filtering in the router.
scanning of location A shows ports 80 and 32015 open. Port 4500 is not open (but perhaps my tool checks only TCP?).
scanning of location B shows port 80, but neither 32015 or 4500 are open.
It is curious that ports 80 show open in both locations, suggesting that the router in Location A is exposed to the internet (as expected, it’s behind a cable modem) and port forwarding in Location B does work.
That port 32015 shows closed in Location B is odd. Since port 80 shows open, it looks like the problem may be with the PepLink? How would I diagnose this? I have no firewall rules for ports 32015 or 4500.
Also, given that port 32015 is open in Location A, shouldn’t the router in Location B be able to connect?
Sorry for all these questions and many thanks for help!
Location B also needs to have port 32015 open. This is needed for the TCP handshake. As the handshake is 2 way traffic both sites need to have the ports open.
The Peplink doesnt block ports by default. What kind of Modem do you use at site B ?
What you can try is put the modem in bridge mode and let the Peplink handle network ect.
It could be you need to contact your ISP to make this possible
If site A has a public address and can be reached on TCP 32015 and UDP 4500 then the site B cn cope happily behind a NAT firewall as long as there are no rules blocking outbound traffic on the 2 ports.
The site B profile should know the Site A IP address in the profile and you should make sure that the remote site ID matches the local ID for each of the sites.
We have just published a video on youtube demonstrating this and also showing some of the errors you may see.
