I’m working on a very odd problem, and I’ve been chasing my tail for days. My question is two-fold, what would be causing it… and, what are some good methods for port specific troubleshooting to overcome similar problems that I may encounter.
I have a remote site (a mobile trailer unit) with a server running a one port TCP service. This unit has a Balance 310 unit in it, with the HQ being the other end of the VPN tunnel.
Everything works fine in both locations. Both routers are routing the traffic between the two subnets correctly. But… As soon as I port forward traffic down from the ISP at the HQ to an IP address that exists on the other end of the tunnel, it fails.
The remote unit server is accessible from either LAN on the service port. So the traffic to the port is making it across the tunnel.
What am I missing here? Surely it’s something small. I’m going to draw up the configuration to better explain the setup, and include some of the subnet/equipment information.
Run a packet capture on both B310’s (from the support.cgi page) and then review to see if the traffic arrives at the remote site.
I suspect you have additional firewall settings on one or both of your B310s or on the server itself that is blocking it. Remember the the server will see the source traffic as not from its local LAN segment… and if the USG is not doing SNAT then the server will see the source IP as the public IP of the requester…
1 Like
And welcome to the forum!
1 Like
Did you open the firewall for that port? When you send traffic from one LAN to the other via the VPN the firewall opens automatically. The B310 will see the external traffic from your ISP being sourced somewhere other than the HQ LAN.
You’ll need a rule on the B310:
source=any
source port = any
destination = server LAN address
destination port = your TCP service
1 Like
Right now I have the firewall wide open, set to allow Any/Any on both inbound and outbound, I went through and made sure both were cleared out though.
I did a packet capture and I definitely see the packets making it all the way to the service, that computer just never responds to them. It seems to be agnostic to the service, it reacts the same when trying to open a telnet server on the port and just trying to get to that from the outside. In the capture you can see the remote IP (an AT&T address, as I was using my phone as the test subject) try four times to authenticate.
I’ll try looking the other direction to see where it gets stopped.
Here is the packet when I successfully connect from one side of the tunnel (HQ side) to the other (trailer). Looks like the port mapping is 1:1. Is there some kind of STUN setting not enabled upstream? Very odd. It seems like something in my upstream network and the Peplink is not causing it.
Sounds like the firewall on your server is blocking the source.
1 Like
