Cannot reach my Nextcloud externally
-
I have been running PfSense and a Nextcloud server for a while and it always worked fine. Couple days ago i noticed i cannot reach my nextcloud from outside my network.
I have forwarded 80 & 443 (NAT). Internally it works fine.
Cloud.mydomain.nl points towards the right internal address.Config.php has got the right address in there.
The weird thing is i am not seeing anything being blocked in my fw. It looks like when you enter cloud.domain.nl it doesnt even reach my fw. I don't get a 404 or a different error. It just doesnt seem to load.
PfSense is on 2.6.0CE Nextcloud 26.0.1
-
@operations So you have a port forward on the WAN. Do you see any states being created?
The IP of nextcloud internally matches the port forward rule? -
@michmoor said in Cannot reach my Nextcloud externally:
@operations So you have a port forward on the WAN. Do you see any states being created?
The IP of nextcloud internally matches the port forward rule?Yes the IP matches. What do you mean "any states being created" ? What should be created?
-
@operations said in Cannot reach my Nextcloud externally:
I have forwarded 80 & 443 (NAT). Internally it works fine.
Cloud.mydomain.nl points towards the right internal address.In the internal DNS (split)?
Outside your network it you point to your public IP.
It looks like when you enter cloud.domain.nl it doesnt even reach my fw. I don't get a 404 or a different error
Yeah, @michmoor mentioned already to check if the pass rule shows any additional states after trying to access.
If not check if you even have a real public IP on pfSense. Maybe your ISP changed something. -
@viragomann said in Cannot reach my Nextcloud externally:
@operations said in Cannot reach my Nextcloud externally:
I have forwarded 80 & 443 (NAT). Internally it works fine.
Cloud.mydomain.nl points towards the right internal address.In the internal DNS (split)?
Outside your network it you point to your public IP.
It looks like when you enter cloud.domain.nl it doesnt even reach my fw. I don't get a 404 or a different error
Yeah, @michmoor mentioned already to check if the pass rule shows any additional states after trying to access.
If not check if you even have a real public IP on pfSense. Maybe your ISP changed something.Okee. Split DNS no. I run ad.domain.nl Internally. Nextcloud has cloud.domain.nl.
In my domain dns (domain provider), could.domain.nl points to 213...1 which is part of my paid /29 ipv4 block. This cannot change and so hasn't changed.On 213...2 i run exchange, this server is on the same vlan as nextcloud. This uses the same NAT rules (which different external and intern IP of course) and this is working fine externally.
How do i check these "additional states" when i try to access? Diagnose / States and then? Which IP (external / internal) should look for as Dest /Src or...?
-
@operations said in Cannot reach my Nextcloud externally:
On 213...2 i run exchange, this server is on the same vlan as nextcloud. This uses the same NAT rules (which different external and intern IP of course) and this is working fine externally.
So it's expected that access to Nextcloud works as well from outside.
So maybe it's on Nextcloud.To get sure, sniff the traffic on the WAN and the internal vlan interface. So you can see if packets arrive on WAN and if they forwarded correctly.
If so you can rule out a failure outside your network and on pfSense. -
@viragomann said in Cannot reach my Nextcloud externally:
@operations said in Cannot reach my Nextcloud externally:
On 213...2 i run exchange, this server is on the same vlan as nextcloud. This uses the same NAT rules (which different external and intern IP of course) and this is working fine externally.
So it's expected that access to Nextcloud works as well from outside.
So maybe it's on Nextcloud.To get sure, sniff the traffic on the WAN and the internal vlan interface. So you can see if packets arrive on WAN and if they forwarded correctly.
If so you can rule out a failure outside your network and on pfSense.What you mean by "sniff" when i simply look at the firewall i don't see the traffic coming in. When i ping that 213...1 i do see that traffic.
And i am still not sure what to do with that looking at states. Could you elaborated?
-
@operations
Are you able to post a screen shot of your WAN rules and your port forward? -
@operations
With states I mentioned the number of states shown on the rule tab:
You can check if this increases, when you trigger a request from outside.However, sniffing the traffic is more reliable.
pfSense has a Diagnostoc > Packet Capture implemented for this purpose.Select the WAN interface, set the protocol to TCP and maybe port to 443 and the host to the public NC IP. Start the capture, trigger an access from outside, stop it and look if you see a proper traffic.
If so, set the interface to your internal, change the host filter the the source IP (your WAN IP might not be seen here) and take a new capture. -
@michmoor said in Cannot reach my Nextcloud externally:
@operations
Are you able to post a screen shot of your WAN rules and your port forward?
-
@viragomann said in Cannot reach my Nextcloud externally:
@operations
With states I mentioned the number of states shown on the rule tab:
You can check if this increases, when you trigger a request from outside.However, sniffing the traffic is more reliable.
pfSense has a Diagnostoc > Packet Capture implemented for this purpose.Select the WAN interface, set the protocol to TCP and maybe port to 443 and the host to the public NC IP. Start the capture, trigger an access from outside, stop it and look if you see a proper traffic.
If so, set the interface to your internal, change the host filter the the source IP (your WAN IP might not be seen here) and take a new capture.Yes i did the capture package and i see the traffic (84.1.1.100 is my phone cellular IP, 185.1.1.3 is External Nextcloud):
22:06:17.386222 IP 185.1.1.3.443 > 77...114.52627: tcp 1436
22:06:24.800383 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:24.800528 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 0
22:06:24.845135 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:24.846488 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 517
22:06:24.847775 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 0
22:06:24.847819 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1200
22:06:24.847826 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 483
22:06:24.848010 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:24.848017 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:24.848022 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1248
22:06:24.884221 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:24.893140 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:24.893288 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:24.893376 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:24.893394 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:25.142164 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:25.642290 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:26.666132 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:27.109886 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 0
22:06:27.110836 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 0
22:06:27.145505 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 0
22:06:27.184472 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 517
22:06:27.184861 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 0
22:06:27.199418 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:27.199435 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:27.199442 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1248
22:06:27.199454 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 483
22:06:27.246468 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 0
22:06:27.246481 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 0
22:06:27.274180 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:27.562292 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:28.138181 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:28.682148 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:29.258226 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:31.466115 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:32.746093 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:36.074129 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:39.776599 IP 213...2.62380 > 185.1.1.3.443: tcp 1
22:06:39.777107 IP 185.1.1.3.443 > 213...2.62380: tcp 0
22:06:40.938053 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 1424
22:06:45.034521 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 1424
22:06:50.666029 IP 185.1.1.3.443 > 77...114.52627: tcp 1436
22:06:54.854983 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:54.855310 IP 185.1.1.3.443 > 84.1.1.100.63328: tcp 0
22:06:54.896590 IP 84.1.1.100.63328 > 185.1.1.3.443: tcp 0
22:06:56.118165 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 0
22:06:56.118335 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 0
22:06:56.156499 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 0
22:06:56.158811 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 517
22:06:56.158892 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 0
22:06:56.160058 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:06:56.160068 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:06:56.160074 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1248
22:06:56.160085 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 483
22:06:56.194617 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 0
22:06:56.194640 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 0
22:06:56.217976 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:06:56.462253 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:06:56.969958 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:06:57.189386 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 0
22:06:57.190012 IP 185.1.1.3.443 > 84.1.1.100.63329: tcp 0
22:06:57.221443 IP 84.1.1.100.63329 > 185.1.1.3.443: tcp 0
22:06:57.962063 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:06:59.913995 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:07:02.343118 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 0
22:07:02.343286 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 0
22:07:02.385579 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 0
22:07:02.393435 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 517
22:07:02.393637 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 0
22:07:02.393947 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:02.393956 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:02.393961 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1248
22:07:02.394530 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 483
22:07:02.432156 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 0
22:07:02.446111 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 0
22:07:02.469989 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:02.725896 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:03.241928 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:03.977920 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:07:04.266616 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:06.313966 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:10.377845 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:11.913849 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 1424
22:07:18.570959 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 1424
22:07:26.189684 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 0
22:07:26.189980 IP 185.1.1.3.443 > 84.1.1.100.63330: tcp 0
22:07:26.233853 IP 84.1.1.100.63330 > 185.1.1.3.443: tcp 0
22:07:32.429326 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 0
22:07:32.429598 IP 185.1.1.3.443 > 84.1.1.100.63331: tcp 0
22:07:32.470224 IP 84.1.1.100.63331 > 185.1.1.3.443: tcp 0
22:07:37.769779 IP 185.1.1.3.443 > 213...2.62380: tcp 1436
22:07:39.804971 IP 213...2.62380 > 185.1.1.3.443: tcp 1
22:07:39.805167 IP 185.1.1.3.443 > 213...2.62380: tcp 0
22:07:56.201561 IP 185.1.1.3.443 > 77...114.52627: tcp 1436
22:07:56.243384 IP 84.1.1.100.63334 > 185.1.1.3.443: tcp 0
22:07:56.243551 IP 185.1.1.3.443 > 84.1.1.100.63334: tcp 0
22:07:56.243897 IP 84.1.1.100.63335 > 185.1.1.3.443: tcp 0
22:07:56.243991 IP 185.1.1.3.443 > 84.1.1.100.63335: tcp 0
22:07:56.275285 IP 84.1.1.100.63334 > 185.1.1.3.443: tcp 0 -
@operations on the nextcloud server i would do a tcpdump for good measure to make sure you are seeing the packets from your mobile.
$ sudo tcpdump host 84.1.1.100
If yo are seeing it making it to your server then the fault is within your nextcloud configuration. pfSense is passing the traffic.
-
@operations
So you can see requests and responses as well on the WAN. I would expect that the client who initiated this connection show anything, but doesn't run into a timeout.Is there also another website hosted on the NC server, which you can try?
-
@viragomann said in Cannot reach my Nextcloud externally:
@operations
So you can see requests and responses as well on the WAN. I would expect that the client who initiated this connection show anything, but doesn't run into a timeout.Is there also another website hosted on the NC server, which you can try?
Yes i forgot that add that, if you what long enough it will run it a ERR_TIME_OUT (when trying to open cloud.domain.nl). No Nextcloud server only runs nextcloud.
-
@michmoor said in Cannot reach my Nextcloud externally:
@operations on the nextcloud server i would do a tcpdump for good measure to make sure you are seeing the packets from your mobile.
$ sudo tcpdump host 84.1.1.100
If yo are seeing it making it to your server then the fault is within your nextcloud configuration. pfSense is passing the traffic.
Did this. See a lot of lines:
Cloud.domain.nl > 84.1.1.100But why is my PfSense fw not showing the traffic i am seeing when using tcpdump? Is that because the connection fails? But still it goes through so it should show on the fw .. right?
So the problem is my Nextcloud right? Any ideas on that part?
-
@operations What does your WAN rules show?
-
@michmoor said in Cannot reach my Nextcloud externally:
@operations What does your WAN rules show?
This way i showed before. Or you want to see something else?
-
@operations The bottom rule has 2 states which means the firewall permitted the traffic to 172.16.20.250.
As i suggested before you should run a packet capture on your nextcloud server and see if you see traffic from your mobile device. -
@michmoor said in Cannot reach my Nextcloud externally:
@operations on the nextcloud server i would do a tcpdump for good measure to make sure you are seeing the packets from your mobile.
$ sudo tcpdump host 84.1.1.100
If yo are seeing it making it to your server then the fault is within your nextcloud configuration. pfSense is passing the traffic.
@michmoor the traffic reaches my nextcloud server. I dont know where the button states 2/ is coming from. The numbers are zero now whatever i do
-
@operations said in Cannot reach my Nextcloud externally:
the traffic reaches my nextcloud server.
How do you know?
@operations said in Cannot reach my Nextcloud externally:
I dont know where the button states 2/ is coming from.
It comes from the fact there were 2 states , connections allowed, based on the rule. If the number is 0 that means the previous states are now gone and no new connections have been seen.