SOHO 3 IS NOT FULLY SECURE FROM YOUR ADSL ROUTER WITHOUT THIS CONFIG: KEEPING YOUR LAN SAFE FROM HACKERS (see answer at the bottom) :-)


#1

Hi, I have a Pepwave 3 Surf Solo running the latest Firmware but I’m a little confused, my SOHO is behind a standard DHCP router connected to the Outside world via my ISP and giving me a Nat’d IP in the range of (say) 192.168.x.x and obviously without the Pepwave I can simply plug into it, pickup a LAN IP and browse.

I purchased the Surf to act as a Firewall behind it, issue a different IP range (2nd NAT) :slight_smile: of (say) 10.x.x.x and then allow me to browse normally from the ‘trusted side’ of it. Now it all works and I was happy enough thinking I had a good isolated system . . .

However and quite by chance I ran an IPScan on the 192.168.x.x range (from behind the SOHO and in the 10.x.x.x range) and found to my surprise that I could not only see the main WAN router, but also an IP camera that was connected on that ‘untrusted’ network AND even log into them quite happily.

I appreciate that this traffic may be a one way road (in other words if I initiate it from my SOHO trusted interface that’s allowed but nothing can be initiated from the WAN?), but in previous Firewalls that I’ve used, there is complete isolation from the Firewall LAN and the WAN it’s connected to apart from to route internet traffic.

How do I achieve this on the SOHO? It seems an odd default position they are shipped with and I’m not at all comfortable with the (apparent) lack of isolation? Thanks Tereza


Firewall Inbound Access to Dynamic IP
#2

Really is nothing to worry about. Peplink router products all have a stateful firewall that will refuse all inbound traffic on the WAN unless there is a preexisting session that was started from the LAN to that WAN IP - that in combination with NAT (rather than IP Forwardng) on the WAN is how nearly all NAT routers work. And actually is a tidy way of retaining access to devices in your DMZ (the 192.168.1.0/24 range).

If you want to restrict WAN to LAN traffic completely to just the IP of the ISP router (ie 192.168.1.1) Change the default Inbound firewall rule to Deny (in Network > Firewall | Access Rules) and then add a new rule above that allows traffic from the ISP router:


#3

Change the default Inbound firewall rule to Deny (in Network > Firewall | Access Rules) and then add a new rule above that allows traffic from the ISP router:
image.

Done it and thanks a lot, security is absolutely paramount to me. By the way, do you know if the PEPWave uses DNSmasq on port 53? I believe there are 7 major security flaws on it and I’d like to know if it uses it, and if so, whether the current Firmware includes the patches (7.02). Thanks


#4

Good stuff.

The Peplink engineering team will reply to that question with authority shortly I’m sure, but unless the firmware has changed drastically since I left over a year ago they are not using DNSmasq.


#5

I have noticed the same thing. The Surf SOHO allows outbound requests to IPs that are supposed to be reserved for private use only. One good side effect of this is that you can access a modem at 192.168.100.1.

To prevent a device on your inner LAN (10.x.x.x) from being able to see your outer LAN (192.168.x.x) set up three firewall rules in Advanced -> Access Rules.

First rule should block access to 10.0.0.0 as a slash 8.
Second rule should block access to 172.16.0.0 as a slash 12
Final rule should block access to 192.168.0.0 as a slash 16

For good luck, you can set these rules to log any activity to the Event Log.

As for other direction (outer LAN -> inner LAN), it should be blocked by normal Surf SOHO default firewall rules. For more about isolation devices into a VLAN see
https://www.routersecurity.org/pepwavesurfsofo.php#guestnetworks


#6

Thanks Michael, so what exactly would you do on the rule (on say the 10.x.x.x subnet)
First up I’d imagine we’re talking about Outbound Firewall Rules? Can you send me the
break down of what the rules would look like? Thanks


#7

Now this is an interesting point. Certainly in the old days of DSL routers with integrated modems (and so a single WAN), it would be a safe assumption that the WAN in this case (the DSL modem) is connected to the internet and as such those private IP Addresses (as detailed in RFC 1918) should not be accessible on the WAN.

However in a multi-WAN environment that the Peplink routers have specifically been designed for- particularly in the targeted original use case of combining Internet connectivity and private WAN links (MPLS and point to point leased lines) which was typical back then, restricting private IP address routing on the WAN doesn’t make as much sense - certainly from a support perspective, since there would likely have been private address spaces on the WAN of the router.

Nowadays, I see Peplink routers being primarily used for bandwidth aggregation and failover across multiple internet links as the major trend, and as such you’re right that routing to private addressing should arguably be restricted on the WAN. However, one of the primary design goals of all Peplink devices is that they should be as easy to use as possible (and work straight out the box for the majority of users) and I think that restricting routing to private addressing WAN side would not achieve those goals.

As always its a balance of utility over security, and personally - at least on this specific issue, I don’t mind.


#8

@terezar these rules would sit in your outbound firewall rules.


#9

Thanks both, sadly the rules crashed any chance at using a web browser! Created a static rule at the top to allow any traffic from 10.0.0.0/24 to go to the solo router IP 192.168.x.x and then blocked out all traffic from the 3 subnets as suggested. Results were mixed! Working from the Cli I could nslookup/dig any Domain or URL I wanted, but none of the web browsers would load - struggling with certification methinks. Any other ideas/refinements?!! Thanks


#10

Sussed it!!

1st rule: Any - 10.0.x.0/24 - 192.168.x.1 Allow (so anything in the 10.0.x.0 range between 1 and 254 can reach the ADSL modem)

2nd rule: Any - 192.168.x.0/24 - 192.168.x.1 Allow (so anything in the 192.168.x.0 range between 1 and 254 can reach the ADSL modem)

3rd Rule: Any - 10.0.0.0/8 - 192.168.0.0/8 Deny (so no traffic from a 10 subnet is getting out of the 192.168 subnet)

4th Rule: Any 172.16.0.0/12 - 192.168.0.0/8 (ditto above but just blocking the 172.16 subnet)

5th Rule: Any - 192.168.0.0/16 - 192.168.0.0/8 (so nothing on the secondary ‘guest’ LAN can reach anything on the 192.168.x.0 subnet

and then the default any - any allow rule

Worked a treat - thanks Guys.

Now tell me, how do we get rid of the admin user in the Cli/ssh? It’s not great that the Pepwave allows you to think you’ve changed your administrator account name, but that’s only on the GUI, any Professional worth his salt is not interested in a 443 webpage as they try to hack into a system!!!

Thanks


#11

Glad you got it working. For the record the Outbound Firewall Rules (Advanced -> Access Rules) would share these settings:

Protocol any
source IP & Port: Any Address
Action: Deny

and then the three rules would be

Destination IP & Port: Network 10.0.0.0 Mask 255.0.0.0 (/8)
Destination IP & Port: Network 172.16.0.0 Mask 255.240.0.0 (/12)
Destination IP & Port: Network 192.168.0.0 Mask 255.255.0.0 (/16)

These would be defaults, and as was said earlier, exceptions would have be specified above these three rules.

User admin for SSH seems to be a bug, I’ll report it.

No Peplink admin web page should ever use port 443. They let you specify a non-standard port and you should do so.


#12

Hi Michael, I’m not so sure on your ‘for the record’ rules; When implemented on my Firewall they worked in terms of ping testing and network mapping but completely broke all Browser use and Browser access to the Outside world - try it and you’ll see. So the rules I added to resolve this (and above yours in the list) were to:

Allow both Main and Guest subnets access SOLELY the external router IP which then resolved the Browser issues, but ensure both Guest and Main subnets can route nowhere else apart from the external IP of the router through your rules. Happy to change but it seemed to do the job and previously as I mentioned the Firewall effectively blocked all Browser traffic


#13

My bad, sorry. These rules by themselves block all access to your outer LAN. You would need to poke a hole in this to allow access to the outer router/gateway device. Specifically, add a new rule at the top of the list (they are evaluated top down) allowing access to 192.168.1.1 or whatever the LAN side IP address of the outer router is.


#14

REVISED AND FINAL CONFIGURATION TO SECURE/ISOLATE TRUSTED NETWORK FROM WAN.

Hi Michael, I have been tweaking this and I think I have the perfect secure routing (blocking all traffic from the protected LAN to the Router direct).

When you attach the SOHO it automatically assigns itself a ‘WAN’ IP, for instance 192.168.x.5 - so first up make this static so that the SOHO always has this IP when it connects to the WAN

Optional info here: If you can, lock your modem/router down by the MAC address of the SOHO only, turn off DHCP and if it’s clever enough, tell it only accept traffic from the SOHO’s IP that would also be cool :slight_smile:

Now for the important bit - Isolating the secure trusted interfaces on the SOHO from direct communication with the ADSL Modem router:

Outbound Firewall rules

1st rule: Any - 10.0.x.0/24 - 192.168.x.5 Allow (so anything in the 10.0.x.0 range between 1 and 254 can reach the LAN side IP of the SOHO - not the ADSL modem)

2nd rule: Any - 192.168.x.0/24 - 192.168.x.1 Allow (so anything in the 192.168.x.0 range between 1 and 254 can reach the LAN side IP of the SOHO - not the ADSL modem)

3rd Rule: Any - 10.0.0.0/8 - 192.168.0.0/8 Deny (so no traffic from a 10 subnet is getting out of the 192.168 subnet) - thanks to Michael for this rule :slight_smile:

4th Rule: Any 172.16.0.0/12 - 192.168.0.0/8 (ditto above but just blocking the 172.16 subnet) - Thanks again due to Michael :slight_smile:

5th Rule: Any - 192.168.0.0/16 - 192.168.0.0/8 (so nothing on the secondary ‘guest’ LAN can reach anything on the 192.168.x.0 subnet - and yes it’s Michael again I ought to thank!! :slight_smile:

and then the default any - any allow rule


Inbound Firewall rule

Allow: Any (Protocol) - Any (WAN) - 192.168.x.5 (Source IP and WAN side IP of your SOHO) - Destination IP Port: Any


The beauty of this rule set, is it completely isolates ALL traffic on the SOHO direct to or from clients to or from the ADSL/untrusted WAN even if they (the clients) have been compromised and try to initiate the connection with the WAN direct bypassing the Firewall), and it drives ALL traffic from the trusted network(s) through the SOHO (and it’s security systems) which then has the sole responsibility for checking all traffic and passing it onto the ADSL router. It is quite simply - secure :slight_smile: well as secure as anything can be these days!!!

Thanks for your help in getting to the final solution!! Tereza