Web GUI
-
Good afternoon!
There is a server with Pfsense, two providers are connected to it. Both gateways are added to Multiwan. In the System>Advanced menu, I changed the protocol to https and changed the port. The problem is that from the Internet I can’t connect to WEB GUI only on Wan1, but not on Wan2. Other ports are forwarded without problems. The firewall turned on / off - no difference. Tell me, please, where is the error?
Всем добрый день!
Стоит шлюз на Пфсенс, подключены 2 провайдера, но до веб морды могу достучаться только через Wan1. Подскажите, куда копать? -
What kind of multi-WAN configuration is this?
Failover or loadbalance?https://docs.netgate.com/pfsense/en/latest/routing/multi-wan.html
-
Loadbalance.
-
correct configuration at first glance:
Are other services available from outside, on both WAN IPs?
I will be honest, we have 3 multi-WAN configured pfSnese, but we handle it remotely with OpenVPN.
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/openvpn-remote-access-server.html
Not via https, so this them interests me too.i don't know if pfSense pairs the dashboard (web), for example, specifically for WAN1 in load balancer mode and primarily (that wouldn't make sense )
this question also::
-
-
Please unplug the WAN 1 ethernet connector (if you can do this now depends on your environment) and see how this round-robin works
so,
" When two gateways are on the same tier, they will load balance. This means that on a per-connection basis, connections are routed over each WAN in a round-robin manner. If any gateway on the same tier goes down, it is removed from use and the other gateways on the tier continue to operate normally." -
Thanks, but that doesn’t explain why I cannot open WebGUI on both Wan1 and Wan2 at the same time.
-
there were certificat issues yesterday, maybe this will affect something at https, as it affected more everything ???
, you use DDNS?
-
-
true, we never use pfSense with this - https, so because of this:
https://www.netgate.com/blog/securely-managing-web-administered-devices.htmlbut it is very interesting why what has worked so far is not now...
what to see in the firewall log, when you want to connect from outside on WAN2?
it must be a trace of this -
-
so you don’t even get to the firewall with the request that’s a fact..
okay, meanwhile your ISP who is on the WAN2 interface is not volatile in its port filtering rules?
it is suspected that it is exactly the beginning of the month.. -
so you don’t even get to the firewall with the request that’s a fact..
okay, meanwhile your ISP who is on the WAN2 interface is not volatile in its port filtering rules?
it is suspected that it is exactly the beginning of the month..I was informed that one of the providers fell off yesterday. On the second ip it was no longer possible to enter. After a working day I'll try to restart, maybe it will help
Thanks for the help) -
you welcome
-
@DaddyGo No it didn't help
-
the fact is that if you don't see an entry in the firewall log about the attempt, it's not pfSense that is causing the error
the package / request / etc. does not reach the pfSense
it is not possible for pfSense to cancel the connection attempt, ergo the process is interrupted somewhere before it
@Илья I was informed that one of the providers fell off yesterday.
so this ISP thing is definitely the source of your problem -
Even when I turn off the firewall, packets do not fly by. Moreover, the port is pushed inside with this ip, that is, the address is available. For some reason, there is no access only to the GUI
-
It is periodically unavailable even from LAN
After reboot, I turn off / on the firewall, and from the LAN I can access the GUI through the second address. But it’s impossible to get through from the Internet.
LOL) I can redirect packets from a “non-working” ip to the LAN address of the gateway, and then everything works. -
What IPs do you use on WANs?
Are these ISP public (fixed) IPs?Can you send a log snippet of dpinger?
-
Send text or picture?
-
print screen, the best, as I did
-
There it is
-
huhhh....
this shows that you only have one ISP public IP on WAN 1
RFC1918 address is configured on WAN2 (this could easily be one dual -NAT on WAN2?)
and you have a VPN gateway configured as wellthis is not a pure dual-ISP load balance setting with multi -WAN
what does your gateway setting look like?
-
Hi,
Always take in account that 8.8.8.8 was build with on goal in mind : serving DNS requests on it's port 53.
If it has time to do something else - that's how ICMP works - il will reply on ICMP requests.
Then the entire world decided to give 8.8.8.8 all their DNS requests.
All this boils down to : you have to consider that it's maybe not wise to choose a heavenly loaded server as 'ICMP 'test' point.Not receiving an answer on a ping request doesn't break anything **. You might say : the route the ping packet took is over crowded, so it will get ditched immediately.
The dpinger process is counting the returns of a ping. If to many are missing, it will reset your "WAN" connection - this connection might be without any issues, except that further on the route some router decides to throw away a ping packet or two.
I advise you to use/test with another monitor IP ... because if 8.8.8.8 - or the route to it - goes bad, your local connection to the net will really suffer, because dpinger starts to bounce it.
Btw : If you native WAN connection is bad, the traffic that flows through it is also bad : in your case the VPN over the WAN traffic.
** With IPv6 this changes.
-
@Gertjan
the basic problem of the OP is, that with a multi-WAN configuration it is not possible to access the GUI on the second WAN connectionI agree with you about monitor IP:
although it can be seen in my own configuration that I use 1.0.0.1(on the second and VPN gateway) for this purpose, unfortunately the ExpVPN gateway is not pingable
I can't set up VPN GTW monitoring with another gateway - which one?
Plus, CloudFlare has a very fast response time on my location, so I don't spoil my measurement resultssince I also use this for DNS, through the VPN tunnel, so I get the values with a good approximation
any suggestions for external monitor IP?
-
@DaddyGo there it is
-
this doesn't need to be obscured as I have already seen everything from dpinger logs
so, I really can't use what you uploaded (PRTSC)
so, WAN2 gets an internal IP address? (RFC1918), do you get it from another DHCP-capable router on your internal network?
edit: 192.168.80.171 (RFC1918)
-
this doesn't need to be obscured as I have already seen everything from dpinger logs
so, I really can't use what you uploaded (PRTSC)
so, WAN2 gets an internal IP address? (RFC1918), do you get it from another DHCP-capable router on your internal network?
edit: 192.168.80.171 (RFC1918)The policy of this provider is this - the real ip address is looking on the Internet, all requests from it are forwarded to the corresponding address ports 192.168.80.171 - this is the provider subnet
-
Yes, just like a dual -NAT
(what device do you have from your ISP for this configuration)where do you get this IP address?
192.168.80.171 from 192.168.80.1 GTW via DHCP?109.72.249.161 ??? I think this is your public 2 address ISP GTW
what ports are forwarded 109.72.249.161 and it is between 192.168.80.1 - 192.168.80.171what is the GUI access port (on your device)?
it will surely be transmitted across this dual NAT suspicious configuration -
Yes, just like a dual -NAT
(what device do you have from your ISP for this configuration)
where do you get this IP address?
192.168.80.171 from 192.168.80.1 GTW via DHCP?
109.72.249.161 ??? I think this is your public 2 address ISP GTW
what ports are forwarded 109.72.249.161 and it is between 192.168.80.1 - 192.168.80.171
what is the GUI access port (on your device)?
it will surely be transmitted across this dual NAT suspicious configurationI also had a suspicion of NAT
But other ports are forwarded without problems.
The provider claims that all ports are forwarded 1:1, nothing is blocked -
Okay, let's try it
move the GUI port to a good height, such as 50443F.E.:
you know I wouldn't use such an ISP
you still haven't written down your hardwares types and connections methods -
-
you know I wouldn't use such an ISP
I would also change the provider, but we have no analogues)you still haven't written down your hardwares types and connections methods
From all providers settings come via DHCP.And the answer was ?
-
I would also change the provider, but we have no analogues)
From all providers settings come via DHCP. -
if there is no port filtering..... - , you say that 1:1, then something is still missing (NAT-NAT-NAT)
we would expect a drawing from you about the system (in any form, even by hand)
and raise the GUI port to a higher range- I would still pull out the WAN1 cable (if it is possible of course) and see what happens then
-I think you will be surprised what is not working in addition to the GUI yet
the load balancer can hide a lot of things in front of your eyes, if you don't pay attention and you think everything works great on both WANs (Round-robin)
- I would still pull out the WAN1 cable (if it is possible of course) and see what happens then
-
if there is no port filtering..... - , you say that 1:1, then something is still missing (NAT-NAT-NAT)
we would expect a drawing from you about the system (in any form, even by hand)
and raise the GUI port to a higher rangeI would still pull out the WAN1 cable (if it is possible of course) and see what happens then
-I think you will be surprised what is not working in addition to the GUI yetthe load balancer can hide a lot of things in front of your eyes, if you don't pay attention and you think everything works great on both WANs (Round-robin)
-
THX:
-I wonder what tool / device (CPE) produces this?
-do you have access to this tool / device?
-can you change the GUI port?
-what about WAN1 test, can be disconnected and tested -
-I wonder what tool / device (CPE) produces this?
-do you have access to this tool / device?
-can you change the GUI port?
-what about WAN1 test, can be disconnected and tested- device type unknown
- no access to it
- I will change the port for verification and write the result
- WAN1 will not work in the near future
-
сменить провайдера и мне не помешало бы, но, увы, нет идентичного,
-
@valentinius thanks for your comment, but we are beyond that