SpeedFusion and Drop-In mode - seeing networks behind Drop-In Peplink?

Product Discussion Peplink Balance
1

Hello,
We are setting up 8 of these Peplink 380’s (had to get 380’s so we can full mesh). I have gotten the main site going in drop in mode on WAN1 and a mobile internet stick as a backup. I have set up another unit with just a mobile stick for now and was able to create the VPN without any problem. The only thing is that the unit with just the mobile stick only sees the public subnet of the drop-in mode unit, not the subnets it’s connected to. How do we get that working?

1 Like
2

The following steps will accomplish this:

  1. Configure a static route for the internal network on the Balance at the main site pointing to the outside IP address of the firewall. The private network will become a local network to that Balance and this will get advertised across the SpeedFusion VPN to the remote Balance.

  2. The firewall should have a NAT exclusion policy similar to this:

When source = local network
And destination = remote network
Don’t NAT

The Balance at the main site will then see the source packets coming from the inside and route them properly through the SpeedFusion VPN.

3

The outside address of the firewall being the router that we dropped the Balance in between it and the ISP DMZ switch?

4

Correct. The router is assumed to be doing a NAT from the internal networks to its public IP. If it does not do a NAT, only the static routes would be needed in the Balance.

5

OK so I added the subnets of the three networks behind the HQ peplink. One subnet is on the Cisco 1921 router that is behind the peplink, and the other two are routed through the 1921 to another router. For some reason, I’m able to talk to the two other subnets from my remote location but not the subnet that the router is on. We already have a NAT access list:
access-list 3 remark CCP_ACL Category=2
access-list 3 permit 192.168.10.0 0.0.0.255
access-list 3 permit 192.168.20.0 0.0.0.255
access-list 3 permit 192.168.30.0 0.0.0.255
access-list 3 permit 192.168.40.0 0.0.0.255
to which I added the following line, thinking this would do it:
access-list 3 deny 192.168.50.0 0.0.0.255

Doesn’t seem to have helped.

6

OK so I removed the static entry for the subnet that the router is on, and I can now ping the router. I cannot ping any device on that subnet beyond that though. getting closer

7

Here is a map of our setup… I can’t figure out what’s wrong here. on our Cisco 1921 router we have this config:
ip nat inside source list NAT interface GigabitEthernet0/0 overload
ip access-list extended NAT
deny ip 192.168.10.0 0.0.0.255 192.168.50.0 0.0.0.255
deny ip 192.168.11.0 0.0.0.255 192.168.50.0 0.0.0.255
deny ip 192.168.12.0 0.0.0.255 192.168.50.0 0.0.0.255
permit ip 192.168.10.0 0.0.0.255 any

768×614 5.91 KB

So far, I can get to the peplink at remote from the main, and if I log into the peplink at remote, I can ping addresses on the 192.168.10.0 network. I cannot ping the 192.168.11.0 and 192.168.12.0 networks. The responses say they’re from the public IP of the HQ device and not the IP I’m trying to ping though.

8

OK! I got to work this morning and was able to test.
For some reason, from the remote Peplink’s GUI I can ping the 192.168.10.0 network fine, but was getting the public IP of the router behind the HQ’s Peplink. I could not ping 192.168.11.0 or 192.168.12.0. So this morning when I came in, I hooked up to the remote Peplink with my laptop and lo, I am able to access all three HQ subnets just fine. Pings to devices on those networks return responses from the IP I pinged, unlike from the Peplink. I wonder what that could be all about? Looks like we’re OK though.

Now, when adding the rest of these units we should just have to expand that NAT ACL with more deny commands using the new remote site’s subnet.
Going to try just changing the subnet of this remote unit, then adding those lines in the router and see what we get.

9

We’re in business! The only caveat is that you have to do a “no permit 192.168.10.0 0.0.0.255 any” and then a “permit 192.168.10.0 0.0.0.255 any” to remove it from the ACL and re-add it at the bottom of the list, or else it’ll permit before it gets to the new “deny 192.168.10.0 0.0.0.255 192.168.60.0 0.0.0.255”.

And by the way I did end up having to put the static route for all three HQ subnets on the HQ peplink for this to work. My above post saying taking it off helped actually didn’t.
you guys make good gear!

2 Likes
10

Thanks for the update Justin, glad you are up and running! Enjoy your new powerful Peplink network!

We appreciate your business!