This is a different version of something that has been posted here by multiple people: Pepwaves failing PCI compliance scans due to responding on TCP 32015 (speedfusion) and because it fails to pass on the certificate.
This has gone from an annoyance to a major problem due to trustwave expanding the standard scan to cover all these ports, and to fail based on invalid certs.
I know that we can solve the cert issue by manually installing a cert from letsencrypt (you can install a cert for the web admin via incontrol, but not for speedfusion). But I really, really do not want to do that for 400 devices!
But…these pepwaves are the speedfusion remote peer. They all have the OTHER end’s remote IP listed. Why are they even responding to the scan? i.e. if device X is only supposed to connect to Device Y at IP 66.123.123.123, why is device X responding on port 32015 from any other IP? WHy allow people to see/attack this port at all?
So - my request is to have an optional checkbox (default checked) on the speedfusion profile screen saying “Only respond to listed IPs”. if checked, then the pepwave should silently drop any packet to the speedfusion port unless from an ip in the “Remote IP Address / Host Names (Optional)” list
(edit) or…alternatively, if the remote unit has the IP entered for the other end, does it EVER need to respond to unsolicited inbound? Could it just be a checkbox (again default checked) saying “if remote IPs listed, do not respond on inbound requests” or something like that.
I currently have 20 or 30 customers kicking my ass over this.
The reason is that Speedfusion creates tunnels in both directions. Yes, you might only put a public IP of the hub in a remote peer, but when SF initializes, all available WAN IP addressing is shared between the hub and the remote peer and as SF builds across all available WAN links, the hub will also try to build an outbound tunnel to the detected external IP addresses of the remote peer.
This can be really helpful and solves a bunch of scenarios in multi-WAN setups where NAT would otherwise cause havoc.
I like the idea of automatic firewall rules for the SpeedFusion Ports generated based on the IP addressing in the profiles though. Very neat for when its needed.
That makes sense then. but should still be able to limit to only the listed ips (has to allow for all listed ips on all profiles). I tried it with inbound firewall rules but no effect. the speedfusion engine is ahead of the firewall engine in the stack
On a closely related topic - when remote assistance is on PCI scans fail on port 500 open. Could THAT be restricted to only a whitelisted set of IPs at peplink?
This request has been filed and engineering team is working on it.
Quick solution: SpeedFusion supports TLS1.2 and above only since 8.0.0. If your device is running below 8.0.0, you may consider making changes below to ensure the SpeedFusion peers support TLS1.2.
All of my devices are on V8.0. Is there a way to restrict them to only TLS1.2?
The specific failure in the PCI complince scan is
TLSv1.0 Supported 10.00 High Fail Port: tcp/32015
@jmpfas This is not quite possible, since firmware 8.0 we have removed all the legacy protocol so only TLS 1.2 is used (If you are using firmware 7 or below, you need to set Backward Compatibility option to Restricted as per @TK_Liew said in previous post to enforce TLS 1.2). If you really found any devices using firmware 8.0 is failing the scan on TCP port 32015 with TLS 1.0, please open a support ticket and enable Remote Assistance, we will help to check it out immediately.
Hmm. I will have them rescan. But I do want to hav the ability to limit devices to only respond to listed IPs, as a general security measure and to prevent DOS attacks.
I am pushing for this again - just had a customer choose to move their POS system firewall out from behind the pepwave, to be directly on COX on a public IP in order to pass the scan. So they chose to pass this scan instead of continue to have cellular backup. This has GOT to be fixable!
Not a quick fix, but I was able to place a Mikrotik router in front of my Peplink; setup a bridge with firewalling turned on and restrict 32015 from being accessed from anywhere except from the other end of the VPN. Worked for me. All scans pass now.
450??? Oh, man, I hope they come up with something soon. That would really suck. My solutions works, but requires a truck roll and hardware.
One thing I noticed was that I was able to see the traffic coming into the WAN port and port 32015 wasn’t even being used and I could still browse across the VPN. Maybe I’m missing something or it is only used sporadically when renewing the VPN. Still, it would be helpful to have the firewall before the VPN rather than after it when the packets come in.
Good luck, jmpfas, I hope it works out for you and you keep us informed.
I just got lit up on this again. I have an 80 location customer ready to leave me due to failing their scans for months.
I need a custom build that limits 32015 to only listed IPs, and I need it within a few days.
To be specific - where I have several profiles in a rmeote pepwave, each with the far end IP listed, I need to be able to limit so the pepwave will only respond at all on those two IPs.
no - Firmware 8.01 Beta 2 includes a feature Peplink added at my request: “local service firewall rules”. For pepvpn the default is that it blocks all inbound traffic on 32015 or alternate ports except for those you have listed in profiles. You can block random access to various services. I HIGHLY recommend activating this on all devices. It solves the “PCI compliance failure” issues and block brute force attacks on these ports, which can result in real DOS or drive up cellular usage
