Web GUI

Ilya.V

there were certificat issues yesterday, maybe this will affect something at https, as it affected more everything ???

No, we don’t use dnds. By http does not work either, I have no idea what to do.

DaddyGo

true, we never use pfSense with this - https, so because of this:
https://www.netgate.com/blog/securely-managing-web-administered-devices.html

but 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

Ilya.V

@DaddyGo said in Web GUI:

in the firewall log

Not a line about Wan2 in firewall log

DaddyGo

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..

Ilya.V

@DaddyGo said in Web GUI:

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)

DaddyGo

you welcome

Ilya.V

@DaddyGo No it didn't help

DaddyGo

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

Ilya.V

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

Ilya.V

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.

DaddyGo

What IPs do you use on WANs?
Are these ISP public (fixed) IPs?

Can you send a log snippet of dpinger?

Ilya.V

Send text or picture?

DaddyGo

print screen, the best, as I did

Ilya.V

There it is Новый точечный рисунок.png

DaddyGo

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 well

this is not a pure dual-ISP load balance setting with multi -WAN

what does your gateway setting look like?

Gertjan

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.

DaddyGo

@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 connection

I 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 results

since 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?

Ilya.V

@DaddyGo there it is

DaddyGo

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)

Ilya.V

@DaddyGo said in Web GUI:

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