Virtual IP without NAT allows for Admin access on WAN
-
@b_levitt said in Virtual IP without NAT allows for Admin access on WAN:
I just noticed that we have a virtual ip that has not been assigned to a 1:1 NAT. The consequence of this seems to be that the admin interface was available on the wan, presumably because of a rule was once allowing web server traffic to the once natted virtual IP.
Then delete that rule.
But is there a rule I can add to make sure this can't happen again? The only direct communication to the firewall on the wan side should be ipsec and openvpn.
You don't need to create a rule, just remove the rule that allows access as there is a default block rule.
Oh, and make sure you are testing from WAN and not through LAN or you'll look rather stupid in the end.
-
The "just make sure" human element is that which I'm trying to mitigate.
I'm not really all that concerned with a rule that allows http traffic to a server that doesn't exist, as all the servers behind this firewall are webservers anyway. But once that server silently becomes the firewall itself, that's a different story.
The fact that the firewall does NOT respond with the management interface on the IP that is directly assigned to the wan, makes me feel like this is a bug. Why does the management interface bind to virtual IPs and not to the actual WAN IP?
I suppose I've already fixed this largely by changing the port, but I'm still surprised that the web server that runs the admin interface is allowing itself to be bound to IPs on the wan side. If changing that is not possible, I'm surprised there isn't a warning indicating the mismatch between virtual IPs and NATs exist.
-
Moving to the vip section
-
Post up your firewall rules for your wan... And from what direction are you accessing this vip.. from your lan side or your wan side?
-
@johnpoz :
The above is the only rule I had for http - like i said, all servers behind this firewall are webservers.
Yes, I confirmed external access on the WAN side with a device not on our lan.
-
Well that is an any any rule for 80... So yeah... WTF were you thinking creating such a rule?
Your rule should of been locked down to actual dest IP(s)..
When you do a port forward pfsense will auto create the rule for you with the destination rfc1918 address as the dest.. If you have public space behind your pfsense without port forwarding.. Then you should create the rule with the dest IP(s) or a cidr dest that is your web servers, etc.
-
I get that and I've changed it - but why does the firewall block http for the admin interface on it's own IP, but not with virtual IPs?
-
The firewall blocks ALL access from the wan unless you create a rule to allow it.. Out of the box all unsolicited traffic inbound is blocked be it the actual wan IP, a vip or whatever.. Out of the box nothing is allowed in the wan - it doesn't even answer ping out of the box, etc.
-
Even with the any/any rule in place. I cannot get to the admin interface on the wan interface IP. It is treating the formally assigned IP and the VIPs differently.
I'm either trying to understand the difference or suggesting a "pit of success" feature. I get that this was messed up - but these rules were translated from another system where all lan ips would be allowed for http and that's what the context for "any" was. Nobody knew that '*' also included the firewall since testing the WAN ip was denied as expected.
-
My guess is there a redirect to https on the wan IP... But possible this redirect doesn't work on vip? And that redirect port is not allowed.
That is a guess..
How could anyone think that * is just lan IPs?? Come on ;) And doesn't include ALL?
-
@johnpoz said in Virtual IP without NAT allows for Admin access on WAN:
My guess is there a redirect to https on the wan IP... But possible this redirect doesn't work on vip? And that redirect port is not allowed.
Confirmed in fiddler that this is not correct. The firewall does not respond to http at all.
How could anyone think that * is just lan IPs?? Come on ;) And doesn't include ALL?
Because all isn't actually all since it doesn't include the wan IP. If we had a successful test case of all doesn't include the wan IP, where does it say that VIPs are different?
-
I have no idea why you would think that * is not ALL and or that it doesn't include VIP..
You had a firewall rule that was dest *... So yeah if something listening on wan or vip you would be able to get to it!
When you create the rule is says ANY... and puts in the *
-
@johnpoz said in Virtual IP without NAT allows for Admin access on WAN:
I have no idea why you would think that * is not ALL and or that it doesn't include VIP..
It's not what I think. Its what I can actually confirm. The firewall does not respond to requests for the admin interface on the WAN IP regardless of rules. Seems to me that it would be a nifty feature to do the same for VIPs.
