forum.ipfire.org

Posted: **August 18th, 2019, 3:06 am**

A few days ago, I noticed that I can't get to some websites anymore from any device in my house. I have tried multiple computers, multiple browsers, and mobile devices and the pages never load. I can ping them and they respond via ping, but they won't load in a web browser. If I turn on my personal VPN, I can connect to them just fine. To rule out that IPfire is causing this issue, I ran a test by connecting the cable modem straight to my laptop and I was able to get to those websites without issue. The problem is definitely with IPfire. What's odd is that I don't even have the web proxy turned on. I have tried rebooting my cable modem a few times and I have rebooted IPfire a few times, but I still can't get those websites. This is really aggravating because one of them is for an online school, for which I teach, and the other website is for my work.

Why is IPfire blocking these domains? Why do they respond via ping but won't load in a web browser?

Edit: I am running Core 134. I was using Quad 9 as my DNS service (9.9.9.9) but just switched it over to Google (8.8.8.

and there is no change. I still can't get to those web sites.

Posted: **August 18th, 2019, 7:49 am**

HI,

axel2078 wrote:I still can't get to those web sites.

URL(s)?

Best,
Matthias

Posted: **August 18th, 2019, 1:06 pm**

FischerM wrote: ↑
August 18th, 2019, 7:49 am
HI,

axel2078 wrote:I still can't get to those web sites.
URL(s)?

Best,
Matthias

Here are they are:

https://fs.mantech.com/adfs/ls/idpiniti ... om/mantech
https://myhub.mantech.com
https://mail.mantech.com
https://worldclassroom.webster.edu
http://apps.webster.edu
http://www.webster.edu

Again, the problematic websites all respond to pings, but won't load in a web browser unless I connect to a VPN. If I connect directly to my cable modem, I can access them just fine. The problem is with IPfire. I've already tried switching the DNS in IPfire from 9.9.9.9 to 8.8.8.8 and to 8.8.4.4, and to 1.1.1.1. The result is the same.

Posted: **August 18th, 2019, 1:24 pm**

Hi,

I tested these:

https://fs.mantech.com/adfs/ls/idpiniti ... om/mantech

Redirect to https://myhub.mantech.com => "404 Error - Page Not Found"

https://myhub.mantech.com

Same as above.

https://mail.mantech.com

Opens "Outlook Web App":

https://worldclassroom.webster.edu

Login screen for "WorldClassroom":

http://apps.webster.edu

Only a text line: "Index page for apps.webster.edu"

http://www.webster.edu

Startpage of "Webster University" - looking normal.

DNS used: DoT over Port 853 with ten different DNS-Servers.

Perhaps you could find something in the logs?

HTH,
Matthias

Posted: **August 18th, 2019, 1:43 pm**

axel2078 wrote: ↑
August 18th, 2019, 3:06 am
Why is IPfire blocking these domains? Why do they respond via ping but won't load in a web browser?

Edit: I am running Core 134. I was using Quad 9 as my DNS service (9.9.9.9) but just switched it over to Google (8.8.8. and there is no change. I still can't get to those web sites.

Hello

Ping and browser use the same path to get from the domain name to a numerical address, so if you can ping, the DNS access is fine (unless you use different computers to test ping and browser, of course). It's certainly a http(s) problem then.

Your blocked sites all use passwords, I don't see how that could be a problem except if you use a proxy. Can you post the output (on the firewall) of:

Code: Select all

grep -i green /var/ipfire/firewall/config
grep -i on /var/ipfire/firewall/geoipblock
cat /var/ipfire/firewall/settings
ls -al /var/ipfire/proxy/enable

Posted: **August 18th, 2019, 1:50 pm**

I'm not sure why you couldn't get to https://myhub.mantech.com. That one loads for me over a VPN.

Can you try this URL? I probably should have provided the full URL before.

http://apps.webster.edu/compcen/datadic ... form2.php3

Obviously you are able to get to these websites, but I am not using IPfire. What logs should I be looking in?

Posted: **August 18th, 2019, 1:55 pm**

gpatel-fr wrote: ↑
August 18th, 2019, 1:43 pm

axel2078 wrote: ↑
August 18th, 2019, 3:06 am
Why is IPfire blocking these domains? Why do they respond via ping but won't load in a web browser?

Edit: I am running Core 134. I was using Quad 9 as my DNS service (9.9.9.9) but just switched it over to Google (8.8.8. and there is no change. I still can't get to those web sites.
Hello

Ping and browser use the same path to get from the domain name to a numerical address, so if you can ping, the DNS access is fine (unless you use different computers to test ping and browser, of course). It's certainly a http(s) problem then.

Your blocked sites all use passwords, I don't see how that could be a problem except if you use a proxy. Can you post the output (on the firewall) of:
Code: Select all
grep -i green /var/ipfire/firewall/config
grep -i on /var/ipfire/firewall/geoipblock
cat /var/ipfire/firewall/settings
ls -al /var/ipfire/proxy/enable

Here is the output. The first command yielded no results, which is why I didn't paste it below.

root@ipfire-64 ~]# grep -i on /var/ipfire/firewall/geoipblock
DJ=on
ZW=on
SV=on
KR=on
SA=on
ZA=on
TM=on
NG=on
HU=on
HT=on
UA=on
GEOIPBLOCK_ENABLED=on
HK=on
RS=on
CN=on
TW=on
IQ=on
LY=on
PK=on
SY=on

[root@ipfire-64 ~]# cat /var/ipfire/firewall/settings
POLICY=MODE2
POLICY1=MODE2

[root@ipfire-64 ~]# ls -al /var/ipfire/proxy/enable
ls: cannot access '/var/ipfire/proxy/enable': No such file or directory

On a side note, I've already tried disabling Guardian, IPS, and turning off Geo-IP block. I still can't get to those sites.

Posted: **August 18th, 2019, 4:16 pm**

can you try from a workstation connected behind your ipfire:

wget https://mail.mantech.com/owa

and

wget https://mail.mantech.com/CookieAuth.dll ... &formdir=1

Posted: **August 18th, 2019, 8:44 pm**

gpatel-fr wrote: ↑
August 18th, 2019, 4:16 pm
can you try from a workstation connected behind your ipfire:

wget https://mail.mantech.com/owa

and

wget https://mail.mantech.com/CookieAuth.dll ... &formdir=1

I tried this from a CentOS host on my network behind IPFire and it just times out.

[user@CentOS ~]$ wget https://mail.mantech.com/owa
--2019-08-18 15:33:52-- https://mail.mantech.com/owa
Resolving mail.mantech.com (mail.mantech.com)... 108.174.241.57
Connecting to mail.mantech.com (mail.mantech.com)|108.174.241.57|:443... failed: Connection timed out.

I also tried it from MacOS using Curl (since it doesn't have wget) and that timed out also.

imac:~ user$ curl -X POST https://mail.mantech.com/owa
curl: (7) Failed to connect to mail.mantech.com port 443: Operation timed out

If I try the other website you referenced, the error is slightly different but it still fails:

[user@CentOS ~]$ wget https://mail.mantech.com/CookieAuth.dll ... &formdir=1
[1] 17090
[2] 17091
[user@CentOS ~]$ --2019-08-18 15:41:15-- https://mail.mantech.com/CookieAuth.dll ... url=Z2Fowa
Resolving mail.mantech.com (mail.mantech.com)... 108.174.241.57
Connecting to mail.mantech.com (mail.mantech.com)|108.174.241.57|:443... failed: Connection timed out.

using curl on MacOS:

imac:~ user$ curl -X POST https://mail.mantech.com/CookieAuth.dll ... &formdir=1
[1] 3982
[2] 3983
imac:~ user$ curl: (7) Failed to connect to mail.mantech.com port 443: Operation timed out

Posted: **August 18th, 2019, 9:47 pm**

axel2078 wrote: ↑
August 18th, 2019, 8:44 pm
I tried this from a CentOS host on my network behind IPFire and it just times out.

[user@CentOS ~]$ wget https://mail.mantech.com/owa
--2019-08-18 15:33:52-- https://mail.mantech.com/owa
Resolving mail.mantech.com (mail.mantech.com)... 108.174.241.57
Connecting to mail.mantech.com (mail.mantech.com)|108.174.241.57|:443... failed: Connection timed out.

It should be relatively easy to debug then. Install tshark on pakfire.
Then run on ipfire:

tshark -i green0 host 108.174.241.57

then run on your Centos station

wget https://mail.mantech.com

You should see at least the SYN packet and either retransmission packets or more on the ipfire screen. Paste it here.

Then same thing but replace green by red:

tshark -i red0 host 108.174.241.57

and run again wget https://mail.mantech.com

Paste the new tshark trace (if any)

Posted: **August 18th, 2019, 10:37 pm**

gpatel-fr wrote: ↑
August 18th, 2019, 9:47 pm

axel2078 wrote: ↑
August 18th, 2019, 8:44 pm
I tried this from a CentOS host on my network behind IPFire and it just times out.

[user@CentOS ~]$ wget https://mail.mantech.com/owa
--2019-08-18 15:33:52-- https://mail.mantech.com/owa
Resolving mail.mantech.com (mail.mantech.com)... 108.174.241.57
Connecting to mail.mantech.com (mail.mantech.com)|108.174.241.57|:443... failed: Connection timed out.

It should be relatively easy to debug then. Install tshark on pakfire.
Then run on ipfire:

tshark -i green0 host 108.174.241.57

then run on your Centos station

wget https://mail.mantech.com

You should see at least the SYN packet and either retransmission packets or more on the ipfire screen. Paste it here.

Then same thing but replace green by red:

tshark -i red0 host 108.174.241.57

and run again wget https://mail.mantech.com

Paste the new tshark trace (if any)

Here's the capture from green 0. I got a lot of retries. I got bored and eventually killed it after the 7th retry.

[root@ipfire-64 ~]# tshark -i green0 host 108.174.241.57
Running as user "root" and group "root". This could be dangerous.
Capturing on 'green0'
1 0.000000000 192.168.15.9 → 108.174.241.57 TCP 74 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29598030 TSecr=0 WS=128
2 1.001897370 192.168.15.9 → 108.174.241.57 TCP 74 [TCP Retransmission] 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29599032 TSecr=0 WS=128
3 3.005929603 192.168.15.9 → 108.174.241.57 TCP 74 [TCP Retransmission] 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29601036 TSecr=0 WS=128
4 7.010032173 192.168.15.9 → 108.174.241.57 TCP 74 [TCP Retransmission] 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29605040 TSecr=0 WS=128
5 15.026191929 192.168.15.9 → 108.174.241.57 TCP 74 [TCP Retransmission] 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29613056 TSecr=0 WS=128
6 31.058549046 192.168.15.9 → 108.174.241.57 TCP 74 [TCP Retransmission] 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29629088 TSecr=0 WS=128
7 63.155256183 192.168.15.9 → 108.174.241.57 TCP 74 [TCP Retransmission] 36130 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29661184 TSecr=0 WS=128

Here's my output from red0. Again, I stopped after the 7th retry.

[root@ipfire-64 ~]# tshark -i red0 host 108.174.241.57
Running as user "root" and group "root". This could be dangerous.
Capturing on 'red0'
1 0.000000000 75.132.128.33 → 108.174.241.57 TCP 74 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29763152 TSecr=0 WS=128
2 1.001904318 75.132.128.33 → 108.174.241.57 TCP 74 [TCP Retransmission] 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29764154 TSecr=0 WS=128
3 3.007925291 75.132.128.33 → 108.174.241.57 TCP 74 [TCP Retransmission] 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29766160 TSecr=0 WS=128
4 7.016032537 75.132.128.33 → 108.174.241.57 TCP 74 [TCP Retransmission] 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29770168 TSecr=0 WS=128
5 15.024179315 75.132.128.33 → 108.174.241.57 TCP 74 [TCP Retransmission] 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29778176 TSecr=0 WS=128
6 31.056512785 75.132.128.33 → 108.174.241.57 TCP 74 [TCP Retransmission] 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29794208 TSecr=0 WS=128
7 63.153213321 75.132.128.33 → 108.174.241.57 TCP 74 [TCP Retransmission] 36146 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=29826304 TSecr=0 WS=128

Posted: **August 19th, 2019, 6:01 am**

Well, as far as I can tell, your Ipfire box is doing everything right.
First a bit of explanation: a TCP connection is done through the exchange of 3 packets;
- emitter sends a SYN packet
- receiver replies with an ACK packet
- emitter replies to the ACK packet with another ACK packet
that's called the three-way handshake.
Now what the first trace show is that your ipfire receives correctly the first SYN packet from your station (never assume anything...), the green interface never sends an ACK in reply to your station, said station then retries because it thinks first packet was lost due to some network hasard.
The second trace shows that ipfire does the routing part correctly: the SYN packet is forwarded through the red interface to the correct IP address, the sending address is masqueraded. There is nothing that could prevent the receiver to address an ACK back. Yet nothing is received. It's not ipfire that is blocking the reply, nothing is received by the red interface.

Now the mystery is why is the web server working correctly when you bypass ipfire and connect directly to the Internet provider box.

Does an identical wget done on the ipfire box itself work ? Does a similar wget on the ipfire box itself addressing a vanilla web site such as google.com work ?

Is there anything between the ipfire box and the Internet provider box else than a physical RJ45 link ?

Posted: **August 19th, 2019, 12:43 pm**

gpatel-fr wrote: ↑
August 19th, 2019, 6:01 am
Well, as far as I can tell, your Ipfire box is doing everything right.
First a bit of explanation: a TCP connection is done through the exchange of 3 packets;
- emitter sends a SYN packet
- receiver replies with an ACK packet
- emitter replies to the ACK packet with another ACK packet
that's called the three-way handshake.
Now what the first trace show is that your ipfire receives correctly the first SYN packet from your station (never assume anything...), the green interface never sends an ACK in reply to your station, said station then retries because it thinks first packet was lost due to some network hasard.
The second trace shows that ipfire does the routing part correctly: the SYN packet is forwarded through the red interface to the correct IP address, the sending address is masqueraded. There is nothing that could prevent the receiver to address an ACK back. Yet nothing is received. It's not ipfire that is blocking the reply, nothing is received by the red interface.

Now the mystery is why is the web server working correctly when you bypass ipfire and connect directly to the Internet provider box.

Does an identical wget done on the ipfire box itself work ? Does a similar wget on the ipfire box itself addressing a vanilla web site such as google.com work ?

Is there anything between the ipfire box and the Internet provider box else than a physical RJ45 link ?

Yes, this is the real mystery. If I use a VPN, I can get to those sites without issue. If I connect directly to the cable modem and bypass IPfire, I can get to them without issue. I just don't understand why most sites will load fine, while others won't, especially since I can ping them.

I will have to try the wget from IPfire when I get home later tonight and see what happens. To answer your other question, no, there is nothing else between my IPfire system and the internet. I have just a simple Red/Green setup. The cable modem is connected to the Red NIC of my IPfire and the other NIC (green) is connected to my internal switch that everything else is connected to.

On a side note, my IPfire system is virtualized on Vmware ESXi and it has worked great for years now...until last week when some websites just time out in the browser. I have a snapshot that I could roll back to, but it would take me back to Core 129. I could try that as a last resort to see if it clears the issue I guess. If I roll back to Core 129, is it going to attempt to upgrade incrementally, or will it try to upgrade straight to Core 134?

Posted: **August 19th, 2019, 9:03 pm**

Ok,this is strange. I just tried a wget directly from IPfire and it made the connection and didn't time out! See below:

bash-4.3$ wget https://mail.mantech.com
--2019-08-19 15:57:11-- https://mail.mantech.com/
Resolving mail.mantech.com... 108.174.241.57
Connecting to mail.mantech.com|108.174.241.57|:443... connected.
HTTP request sent, awaiting response... 302 Object Moved
Location: https://mail.mantech.com/owa [following]
--2019-08-19 15:57:11-- https://mail.mantech.com/owa
Connecting to mail.mantech.com|108.174.241.57|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized ( The server requires authorization to fulfill the request. Access to the Web server is denied. Contact the server administrator. )

Username/Password Authentication Failed.

What's even stranger is that since I did that wget from IPfire, I can now get to all the websites that timed out before. I just tried several from my iMac that didn't work before and they all work now. I just tried them from my phone and they work there too. I tried it again using a different browser (Chrome) on both devices and it worked on that one too. I verified that my VPN is turned off. I have no idea why it started working, but nothing worked until I performed that wget from IPfire. Is it coincidence or did that kick something within the system?

Posted: **August 19th, 2019, 10:06 pm**

Have you rebootet and now got a different IP on red. The traces looks like your ip was blocked by the servers, maybee they was on a blacklist like spamhaus.

forum.ipfire.org

some valid domains getting blocked

some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked

Re: some valid domains getting blocked