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