Limit port 32015 (speedfusion/vpn port) to listed IPs for PCI compliance

#1

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.

1 Like

#2

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.

1 Like

#3

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

0 Likes

#4

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?

1 Like