Page 3 of 5

Re: some valid domains getting blocked

Posted: September 14th, 2019, 6:15 pm
by axel2078
JonM wrote:
September 14th, 2019, 5:45 pm
is it fully off (no boxes checked and STOPPED)?
(sorry for asking but Intrusion Prevention was causing me lots of odd issues also)


Screen Shot 2019-09-14 at 12.42.21 PM.png
Correct. Mine looks the same as yours. However, there are still websites I can’t get to because they time out. Now, I can’t get https://worldclassroom.webster.edu to load when it worked yesterday. Works fine when using a VPN or when bypassing IPfire though.

Re: some valid domains getting blocked

Posted: September 15th, 2019, 2:59 pm
by axel2078
So am I the only IPfire user out there that is running into this issue? I don’t think this started until Core 134. I’m having to rely on a VPN to log into random websites including my school’s) since they time out behind IPfire.

Re: some valid domains getting blocked

Posted: September 15th, 2019, 5:18 pm
by JonM
Sorry to say all of the listed websites (listed here - viewtopic.php?f=27&t=23264#p126871) are accessible for me. I can see a webpage for all.

This website just shows one line of text.
http://apps.webster.edu - shows "Index page for apps.webster.edu"

I'd suggest turning things off (like URL Filter, GeoIP, IPS, etc.) and leave them off until things start working.

EDIT: FYI - I am also in Illinois (near Chicago)

Re: some valid domains getting blocked

Posted: September 15th, 2019, 7:14 pm
by axel2078
JonM wrote:
September 15th, 2019, 5:18 pm
Sorry to say all of the listed websites (listed here - viewtopic.php?f=27&t=23264#p126871) are accessible for me. I can see a webpage for all.

This website just shows one line of text.
http://apps.webster.edu - shows "Index page for apps.webster.edu"

I'd suggest turning things off (like URL Filter, GeoIP, IPS, etc.) and leave them off until things start working.

EDIT: FYI - I am in Illinois also near Chicago
I appreciate you taking the time to answer. I just checked my settings and this is what I've got so far:

Intrusion Prevention: off
GeoIP block: off
Guardian: off
Web proxy: off
URL Filter: off

I still can't get to these websites. It just times out. What's really frustrating is that sometimes they start working, but then other websites time out. I don't know what else to do. I shouldn't have to disable most of the firewall functionality of a firewall to get it to work properly. IPfire has worked great for many years, but now it's becoming more of a hindrance.

Edit: For what it's worth, if there is an app for the website I'm trying to get to, it works fine. For example, sometimes the web site for my work email will time out in the browser, but If I use the app on my phone, it works. Likewise, I often can't get to my school's website in the browser, but if I use the app, it works fine. I've noticed that in many of these cases, if I do a wget from IPfire to one of the websites that won't load in a browser, I get a response back. This seems to be web proxy issue to me, which is odd since I'm not using it.

Re: some valid domains getting blocked

Posted: September 15th, 2019, 7:56 pm
by JonM
So the phone app works and the IPFire wget works. And the desktop/laptop computer cannot get to the websites. Is that correct?

Is it multiple computers that cannot access those site? Or just one?

Re: some valid domains getting blocked

Posted: September 15th, 2019, 8:40 pm
by axel2078
JonM wrote:
September 15th, 2019, 7:56 pm
So the phone app works and the IPFire wget works. And the desktop/laptop computer cannot get to the websites. Is that correct?

Is it multiple computers that cannot access those site? Or just one?
Correct. It’s all computers and all browsers. If I use my VPN, there are no problems. If I bypass IPfire and connect straight to the cable modem, there are no problems.

Re: some valid domains getting blocked

Posted: September 15th, 2019, 10:11 pm
by gpatel-fr
I assume that you have retried the traces with tshark and the result is the same, that is, ipfire is seen receiving a packet on green0 and retransmitting it on red0 but without getting any answer.
Logically, a difference should exist between a connection packet (SYN) sent directly by ipfire, that get a reply (ACK) and a connection packet retransmitted by ipfire where there is no answer from the destination. The switch -x allows to display the full packet. If you can try to get a trace, only the first packet is interesting.
So for example

tshark -x -i red0 host 108.174.241.57

then from your station wget mail.mantech.com
get only the first packet getting out of red0

and from another session on your ipfire
wget mail.mantech.com

same thing get only the first packet (unless there is an answer, in this case your site works - or fails differently)

Also when you use a phone it could be interesting to see what is different (are you sure that the phone is not bypassing ipfire ?)

Possibly of interest: ifconfig green0, ifconfig red0, and iptables -n -t nat -L, iptables -n -t filter -L

Re: some valid domains getting blocked

Posted: September 17th, 2019, 1:33 pm
by axel2078
gpatel-fr wrote:
September 15th, 2019, 10:11 pm
I assume that you have retried the traces with tshark and the result is the same, that is, ipfire is seen receiving a packet on green0 and retransmitting it on red0 but without getting any answer.
Logically, a difference should exist between a connection packet (SYN) sent directly by ipfire, that get a reply (ACK) and a connection packet retransmitted by ipfire where there is no answer from the destination. The switch -x allows to display the full packet. If you can try to get a trace, only the first packet is interesting.
So for example

tshark -x -i red0 host 108.174.241.57

then from your station wget mail.mantech.com
get only the first packet getting out of red0

and from another session on your ipfire
wget mail.mantech.com

same thing get only the first packet (unless there is an answer, in this case your site works - or fails differently)

Also when you use a phone it could be interesting to see what is different (are you sure that the phone is not bypassing ipfire ?)

Possibly of interest: ifconfig green0, ifconfig red0, and iptables -n -t nat -L, iptables -n -t filter -L

Right now, the only sites I can't seem to access (that I know of) are these:

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

I will try the tshark traces as you mentioned above against https://worldclassroom.webster.edu but since there are multiple IPs that return for a lookup on that hostname, I'm hoping I can use a hostname in place of the IP.

Taken from a Linux computer on my network:

[user@CentOS ~]$ wget https://worldclassroom.webster.edu
--2019-09-17 08:26:10-- https://worldclassroom.webster.edu/
Resolving worldclassroom.webster.edu (worldclassroom.webster.edu)... 34.197.146.108, 34.236.11.156, 3.222.218.57
Connecting to worldclassroom.webster.edu (worldclassroom.webster.edu)|34.197.146.108|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.

and the tshark results from that request (first byte, I think):

0000 00 01 5c 68 2e 46 00 0c 29 22 98 8a 08 00 45 00 ..\h.F..)"....E.
0010 00 3c ff 60 40 00 3f 06 92 99 4b 84 a9 0c 22 c5 .<.`@.?...K...".
0020 92 6c a9 a0 01 bb 00 d6 b7 5f 00 00 00 00 a0 02 .l......._......
0030 72 10 4b 35 00 00 02 04 05 b4 04 02 08 0a 35 28 r.K5..........5(
0040 48 3f 00 00 00 00 01 03 03 07 H?........

Taken directly from IPfire:

[root@ipfire-64 ~]# wget https://worldclassroom.webster.edu
--2019-09-17 08:29:21-- https://worldclassroom.webster.edu/
Resolving worldclassroom.webster.edu... 3.222.218.57, 34.197.146.108, 34.236.11.156
Connecting to worldclassroom.webster.edu|3.222.218.57|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized

and the tshark results from that request:

0000 00 01 5c 68 2e 46 00 0c 29 22 98 8a 08 00 45 00 ..\h.F..)"....E.
0010 00 3c c2 9d 40 00 40 06 a5 76 4b 84 a9 0c 03 de .<..@.@..vK.....
0020 da 39 af 4e 01 bb c4 9d de 81 00 00 00 00 a0 02 .9.N............
0030 72 10 d2 d6 00 00 02 04 05 b4 04 02 08 0a 04 50 r..............P
0040 16 6a 00 00 00 00 01 03 03 09 .j........

What I see in the browser when I try to go to https://worldclassroom.webster.edu is that it will try to load for a really long time and then I get a message like "The server failed to respond" or something like that, which is basically a timeout message.

To answer your other question, yes, I'm sure that when I use the apps on my phone to access the same resources that I am not connected to a VPN. For example, there is an app called Teacher which is just an app front-end to the online environment of many schools that use Canvas for their environment. In my case, it loads up worldclassroom.webster.edu. It looks a little different in the app, of course, but it works fine.

Re: some valid domains getting blocked

Posted: September 17th, 2019, 1:54 pm
by axel2078
Update: I just tried going to https://worldclassroom.webster.edu and after about 10 minutes of trying to load the page, it finally loaded. Once inside though, it's just as slow to move from page to page. However, if I use my VPN, it's lightning fast.

I tried going to http://apps.webster.edu/compcen/datadic ... form2.php3 and after trying to load for several minutes, all I got was this error, which is what I usually see:

Safari can't open the page "http://apps.webster.edu/compcen/datadic ... form2.php3" because the server where this page is located isn't responding.

If I try to ping apps.webster.edu from my Mac, I get timeouts like below:

imac:.ssh user$ ping apps.webster.edu
PING apps.webster.edu (198.246.1.107): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4

If I try the same thing from IPfire, it just seems to hang with no output, but if I do a Ctrl+C to cancel, I can see that it tried and failed:

-bash-4.3$ ping apps.webster.edu
PING apps.webster.edu (198.246.1.107) 56(84) bytes of data.
^C
--- apps.webster.edu ping statistics ---
15 packets transmitted, 0 received, 100% packet loss, time 14156ms

NOW, let's turn on my VPN, do the same ping again and see what happens:

imac:.ssh user$ ping apps.webster.edu
PING apps.webster.edu (198.246.1.107): 56 data bytes
64 bytes from 198.246.1.107: icmp_seq=0 ttl=239 time=40.273 ms
64 bytes from 198.246.1.107: icmp_seq=1 ttl=239 time=40.580 ms
64 bytes from 198.246.1.107: icmp_seq=2 ttl=239 time=36.553 ms
64 bytes from 198.246.1.107: icmp_seq=3 ttl=239 time=42.174 ms

Yeah, something is definitely wrong in IPfire.

Re: some valid domains getting blocked

Posted: September 18th, 2019, 5:15 am
by axel2078
Anyone?? I’m getting pretty desperate here. After clearing my browser cache, https://worldclassroom.webster.edu won’t load for me at all. It just times out.

Re: some valid domains getting blocked

Posted: September 18th, 2019, 11:45 am
by gpatel-fr
axel2078 wrote:
September 17th, 2019, 1:33 pm

(...)
Taken from a Linux computer on my network:

[user@CentOS ~]$ wget https://worldclassroom.webster.edu
--2019-09-17 08:26:10-- https://worldclassroom.webster.edu/
Resolving worldclassroom.webster.edu (worldclassroom.webster.edu)... 34.197.146.108, 34.236.11.156, 3.222.218.57
Connecting to worldclassroom.webster.edu (worldclassroom.webster.edu)|34.197.146.108|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.
this is wildy inconsistent with your previous post where the station failed to *connect*.
Here the behaviour of wget seems pretty normal to me. And in your following post, you were referring to an impossibility to ping, that seems more related to a connection failure. This is totally erratic.
That's why I was asking for ifconfig for the 2 interfaces; there are error counters in this output.
axel2078 wrote:
September 17th, 2019, 1:33 pm

To answer your other question, yes, I'm sure that when I use the apps on my phone to access the same resources that I am not connected to a VPN. For example, there is an app called Teacher which is just an app front-end to the online environment of many schools that use Canvas for their environment. In my case, it loads up worldclassroom.webster.edu. It looks a little different in the app, of course, but it works fine.
I was thinking more of a direct connect through the phone's own 3G network, using Ipv6 maybe - ipfire can't protect ipv6 connections.
Are the phone in airplane mode when you connect correctly while the station behind ipfire don't ? I don't know if all phones can use Wifi in airplane mode, the one I use can.

Re: some valid domains getting blocked

Posted: September 18th, 2019, 1:40 pm
by axel2078
gpatel-fr wrote:
September 18th, 2019, 11:45 am

this is wildy inconsistent with your previous post where the station failed to *connect*.
Here the behaviour of wget seems pretty normal to me. And in your following post, you were referring to an impossibility to ping, that seems more related to a connection failure. This is totally erratic.
That's why I was asking for ifconfig for the 2 interfaces; there are error counters in this output.


I was thinking more of a direct connect through the phone's own 3G network, using Ipv6 maybe - ipfire can't protect ipv6 connections.
Are the phone in airplane mode when you connect correctly while the station behind ipfire don't ? I don't know if all phones can use Wifi in airplane mode, the one I use can.
You're right. Based on the wget output, it does appear to be working, however the page never loads in a browser; it just times out....on every computer on my network. I'm still confused as to why I can't ping apps.webster.edu from my network, but it works over a VPN. As far as your question about my phone, I have an iPhone X and I tried putting it in airplane mode and I noticed it disable the wifi automatically, but it did allow me to turn it back on, while still showing that it was in airplane mode. I tried accessing https://worldclassroom.webster.edu again, but it just times out.

I'm also not sure why the problem seems to rotate around websites. Right now, I'm not having any problems at all accessing anything related to the Mantech websites/domains, which I was when I first started this thread. I can get to all of the webster domains except for the two I mentioned previously.

Here is the interface information you requested earlier. I forgot to include it in my post.

[root@ipfire-64 ~]# ifconfig green0
green0 Link encap:Ethernet HWaddr 00:0C:29:22:98:80
inet addr:192.168.15.1 Bcast:192.168.15.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:283819621 errors:0 dropped:0 overruns:0 frame:0
TX packets:344404571 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53907856474 (51410.5 Mb) TX bytes:170090256531 (162210.7 Mb)



root@ipfire-64 ~]# ifconfig red0
red0 Link encap:Ethernet HWaddr 00:0C:29:22:98:8A
inet addr:75.132.x.x Bcast:255.255.255.255 Mask:255.255.240.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:8514342 errors:0 dropped:0 overruns:0 frame:0
TX packets:4487409 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10139228506 (9669.5 Mb) TX bytes:2772329087 (2643.8 Mb)



[root@ipfire-64 ~]# iptables -n -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
CUSTOMPREROUTING all -- 0.0.0.0/0 0.0.0.0/0
CAPTIVE_PORTAL all -- 0.0.0.0/0 0.0.0.0/0
SQUID all -- 0.0.0.0/0 0.0.0.0/0
NAT_DESTINATION all -- 0.0.0.0/0 0.0.0.0/0
UPNPFW all -- 0.0.0.0/0 0.0.0.0/0

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
NAT_DESTINATION all -- 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
CUSTOMPOSTROUTING all -- 0.0.0.0/0 0.0.0.0/0
OVPNNAT all -- 0.0.0.0/0 0.0.0.0/0
IPSECNAT all -- 0.0.0.0/0 0.0.0.0/0
NAT_SOURCE all -- 0.0.0.0/0 0.0.0.0/0
NAT_DESTINATION_FIX all -- 0.0.0.0/0 0.0.0.0/0
REDNAT all -- 0.0.0.0/0 0.0.0.0/0

Chain CAPTIVE_PORTAL (1 references)
target prot opt source destination

Chain CUSTOMPOSTROUTING (1 references)
target prot opt source destination

Chain CUSTOMPREROUTING (1 references)
target prot opt source destination

Chain IPSECNAT (1 references)
target prot opt source destination

Chain NAT_DESTINATION (2 references)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:11000 to:192.168.15.9:22
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:19000 to:192.168.15.13:5900
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:13000 to:192.168.15.133:5900
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:18000 to:192.168.15.16:5900
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:17000 to:192.168.15.13:22
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:10000 to:192.168.15.10:3389
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:9543 to:192.168.15.142
DNAT tcp -- 0.0.0.0/0 75.132.x.x tcp dpt:11095 to:192.168.15.142

Chain NAT_DESTINATION_FIX (1 references)
target prot opt source destination
SNAT all -- 0.0.0.0/0 0.0.0.0/0 mark match 0x1 to:192.168.15.1

Chain NAT_SOURCE (1 references)
target prot opt source destination

Chain OVPNNAT (1 references)
target prot opt source destination

Chain REDNAT (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0 mark match 0x32
MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0

Chain SQUID (1 references)
target prot opt source destination

Chain UPNPFW (1 references)
target prot opt source destination





[root@ipfire-64 ~]# iptables -n -t filter -L
Chain INPUT (policy DROP)
target prot opt source destination
BADTCP tcp -- 0.0.0.0/0 0.0.0.0/0
CUSTOMINPUT all -- 0.0.0.0/0 0.0.0.0/0
P2PBLOCK all -- 0.0.0.0/0 0.0.0.0/0
GUARDIAN all -- 0.0.0.0/0 0.0.0.0/0
IPS_INPUT all -- 0.0.0.0/0 0.0.0.0/0
OVPNBLOCK all -- 0.0.0.0/0 0.0.0.0/0
IPTVINPUT all -- 0.0.0.0/0 0.0.0.0/0
ICMPINPUT all -- 0.0.0.0/0 0.0.0.0/0
LOOPBACK all -- 0.0.0.0/0 0.0.0.0/0
CAPTIVE_PORTAL all -- 0.0.0.0/0 0.0.0.0/0
CONNTRACK all -- 0.0.0.0/0 0.0.0.0/0
DHCPGREENINPUT all -- 0.0.0.0/0 0.0.0.0/0
GEOIPBLOCK all -- 0.0.0.0/0 0.0.0.0/0
IPSECINPUT all -- 0.0.0.0/0 0.0.0.0/0
GUIINPUT all -- 0.0.0.0/0 0.0.0.0/0
WIRELESSINPUT all -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW
OVPNINPUT all -- 0.0.0.0/0 0.0.0.0/0
TOR_INPUT all -- 0.0.0.0/0 0.0.0.0/0
INPUTFW all -- 0.0.0.0/0 0.0.0.0/0
REDINPUT all -- 0.0.0.0/0 0.0.0.0/0
POLICYIN all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP)
target prot opt source destination
BADTCP tcp -- 0.0.0.0/0 0.0.0.0/0
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
CUSTOMFORWARD all -- 0.0.0.0/0 0.0.0.0/0
P2PBLOCK all -- 0.0.0.0/0 0.0.0.0/0
GUARDIAN all -- 0.0.0.0/0 0.0.0.0/0
IPS_FORWARD all -- 0.0.0.0/0 0.0.0.0/0
IPSECBLOCK all -- 0.0.0.0/0 0.0.0.0/0 policy match dir out pol none
OVPNBLOCK all -- 0.0.0.0/0 0.0.0.0/0
OVPNBLOCK all -- 0.0.0.0/0 0.0.0.0/0
IPTVFORWARD all -- 0.0.0.0/0 0.0.0.0/0
LOOPBACK all -- 0.0.0.0/0 0.0.0.0/0
CAPTIVE_PORTAL all -- 0.0.0.0/0 0.0.0.0/0
CONNTRACK all -- 0.0.0.0/0 0.0.0.0/0
GEOIPBLOCK all -- 0.0.0.0/0 0.0.0.0/0
IPSECFORWARD all -- 0.0.0.0/0 0.0.0.0/0
WIRELESSFORWARD all -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW
FORWARDFW all -- 0.0.0.0/0 0.0.0.0/0
UPNPFW all -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW
REDFORWARD all -- 0.0.0.0/0 0.0.0.0/0
POLICYFWD all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
CUSTOMOUTPUT all -- 0.0.0.0/0 0.0.0.0/0
P2PBLOCK all -- 0.0.0.0/0 0.0.0.0/0
IPS_OUTPUT all -- 0.0.0.0/0 0.0.0.0/0
IPSECBLOCK all -- 0.0.0.0/0 0.0.0.0/0 policy match dir out pol none
LOOPBACK all -- 0.0.0.0/0 0.0.0.0/0
CONNTRACK all -- 0.0.0.0/0 0.0.0.0/0
DHCPGREENOUTPUT all -- 0.0.0.0/0 0.0.0.0/0
IPSECOUTPUT all -- 0.0.0.0/0 0.0.0.0/0
TOR_OUTPUT all -- 0.0.0.0/0 0.0.0.0/0
OUTGOINGFW all -- 0.0.0.0/0 0.0.0.0/0
POLICYOUT all -- 0.0.0.0/0 0.0.0.0/0

Chain BADTCP (2 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x29
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x37
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x3F
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x01
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03
PSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
NEWNOTSYN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 ctstate NEW

Chain CAPTIVE_PORTAL (2 references)
target prot opt source destination

Chain CAPTIVE_PORTAL_CLIENTS (0 references)
target prot opt source destination
RETURN udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 limit: up to 3kb/s burst 1mb mode srcip
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 limit: up to 3kb/s burst 1mb mode srcip
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain CONNTRACK (3 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED
DROP all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "h323"
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "ftp" tcp dpts:1024:65535
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "pptp"
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "tftp"
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "irc"

Chain CUSTOMFORWARD (1 references)
target prot opt source destination

Chain CUSTOMINPUT (1 references)
target prot opt source destination

Chain CUSTOMOUTPUT (1 references)
target prot opt source destination

Chain DHCPBLUEINPUT (0 references)
target prot opt source destination

Chain DHCPBLUEOUTPUT (0 references)
target prot opt source destination

Chain DHCPGREENINPUT (1 references)
target prot opt source destination
DHCPINPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain DHCPGREENOUTPUT (1 references)
target prot opt source destination
DHCPOUTPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain DHCPINPUT (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67

Chain DHCPOUTPUT (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68

Chain FORWARDFW (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 192.168.15.9 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 192.168.15.13 tcp dpt:5900
ACCEPT tcp -- 0.0.0.0/0 192.168.15.133 tcp dpt:5900
ACCEPT tcp -- 0.0.0.0/0 192.168.15.16 tcp dpt:5900
ACCEPT tcp -- 0.0.0.0/0 192.168.15.13 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 192.168.15.10 tcp dpt:3389
ACCEPT tcp -- 0.0.0.0/0 192.168.15.142 tcp dpt:9543
ACCEPT tcp -- 0.0.0.0/0 192.168.15.142 tcp dpt:11095

Chain GEOIPBLOCK (2 references)
target prot opt source destination

Chain GUARDIAN (2 references)
target prot opt source destination

Chain GUIINPUT (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:444

Chain ICMPINPUT (1 references)
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8

Chain INPUTFW (1 references)
target prot opt source destination

Chain IPSECBLOCK (2 references)
target prot opt source destination

Chain IPSECFORWARD (1 references)
target prot opt source destination

Chain IPSECINPUT (1 references)
target prot opt source destination

Chain IPSECOUTPUT (1 references)
target prot opt source destination

Chain IPS_FORWARD (1 references)
target prot opt source destination
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 mark match ! 0x70000000/0x70000000 NFQUEUE balance 0:1 bypass cpu-fanout
MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK and 0x8fffffff

Chain IPS_INPUT (1 references)
target prot opt source destination
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 mark match ! 0x70000000/0x70000000 NFQUEUE balance 0:1 bypass cpu-fanout
MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK and 0x8fffffff

Chain IPS_OUTPUT (1 references)
target prot opt source destination
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 mark match ! 0x70000000/0x70000000 NFQUEUE balance 0:1 bypass cpu-fanout
MARK all -- 0.0.0.0/0 0.0.0.0/0 MARK and 0x8fffffff

Chain IPTVFORWARD (1 references)
target prot opt source destination

Chain IPTVINPUT (1 references)
target prot opt source destination

Chain LOG_DROP (0 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain LOG_REJECT (0 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain LOOPBACK (3 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 127.0.0.0/8 0.0.0.0/0
DROP all -- 0.0.0.0/0 127.0.0.0/8

Chain NEWNOTSYN (1 references)
target prot opt source destination
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix "DROP_NEWNOTSYN "
DROP all -- 0.0.0.0/0 0.0.0.0/0 /* DROP_NEWNOTSYN */

Chain OUTGOINGFW (1 references)
target prot opt source destination

Chain OVPNBLOCK (3 references)
target prot opt source destination
RETURN icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED

Chain OVPNINPUT (1 references)
target prot opt source destination

Chain P2PBLOCK (3 references)
target prot opt source destination

Chain POLICYFWD (1 references)
target prot opt source destination
ACCEPT all -- 192.168.15.0/24 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix "DROP_FORWARD "
DROP all -- 0.0.0.0/0 0.0.0.0/0 /* DROP_FORWARD */

Chain POLICYIN (1 references)
target prot opt source destination
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:514
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 LOG flags 0 level 4 prefix "DROP_INPUT "
DROP all -- 0.0.0.0/0 0.0.0.0/0 /* DROP_INPUT */

Chain POLICYOUT (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0 /* DROP_OUTPUT */

Chain PSCAN (7 references)
target prot opt source destination
LOG tcp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 /* DROP_TCP PScan */ LOG flags 0 level 4 prefix "DROP_TCP Scan "
LOG udp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 /* DROP_UDP PScan */ LOG flags 0 level 4 prefix "DROP_UDP Scan "
LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 /* DROP_ICMP PScan */ LOG flags 0 level 4 prefix "DROP_ICMP Scan "
LOG all -f 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5 /* DROP_FRAG PScan */ LOG flags 0 level 4 prefix "DROP_FRAG Scan "
DROP all -- 0.0.0.0/0 0.0.0.0/0 /* DROP_PScan */

Chain REDFORWARD (1 references)
target prot opt source destination

Chain REDINPUT (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68

Chain TOR_INPUT (1 references)
target prot opt source destination

Chain TOR_OUTPUT (1 references)
target prot opt source destination

Chain UPNPFW (1 references)
target prot opt source destination

Chain WIRELESSFORWARD (1 references)
target prot opt source destination

Chain WIRELESSINPUT (1 references)
target prot opt source destination

Re: some valid domains getting blocked

Posted: September 18th, 2019, 7:16 pm
by gpatel-fr
axel2078 wrote:
September 18th, 2019, 1:40 pm

You're right. Based on the wget output, it does appear to be working, however the page never loads in a browser; it just times out....on every computer on my network. I'm still confused as to why I can't ping apps.webster.edu from my network, but it works over a VPN.
Tcp connecting but failing later can point to MTU problems. When there is no connection at all, firewall can be a reason, but when you connect and it fails later it's often MTU related. Is ping blocked somewhere (there are many places it can be) ? Are you sure ping succeeds when it works ?
Often blocking ping can lead to MTU problems, but it could be blocked outside of your network, very often zealous administrators block pings on their network and cause problems elsewhere.
axel2078 wrote:
September 18th, 2019, 1:40 pm

As far as your question about my phone, I have an iPhone X and I tried putting it in airplane mode and I noticed it disable the wifi automatically, but it did allow me to turn it back on, while still showing that it was in airplane mode. I tried accessing https://worldclassroom.webster.edu again, but it just times out.
this suggests that your phone bypass the Ipfire firewall by going though IPV6 on the "3G" network. That's the glory of TCP/IP, it tries to find a way and if you get 2 paths and one is blocked the TCP/IP stack get the other way. I'd guess that when the problem happens you could use your website with your phone app, run tshark on the Ipfire firewall at the same time and see nothing at all going to/from the web site.
axel2078 wrote:
September 18th, 2019, 1:40 pm

I'm also not sure why the problem seems to rotate around websites. Right now, I'm not having any problems at all accessing anything related to the Mantech websites/domains, which I was when I first started this thread. I can get to all of the webster domains except for the two I mentioned previously.
if it's MTU related, the problem can appear/disappear if the network path your compuier is using changes.

axel2078 wrote:
September 18th, 2019, 1:40 pm

(...ifconfig...)
unfortunately no network errors so an easy explanation goes down the drain :-)
the numbers seems a bit strange to me, since I'd expect most ot the received packets on red to go the green network, or most of the received packats on the green network to go to the red network. That's about what I have, but it could be because your blue network is heavily used while mine is not.
axel2078 wrote:
September 18th, 2019, 1:40 pm

(iptables...)
Well, I admit that I did not look at this part of your config closely because it's unlikely a firewall can cause problem when connections succeed (and because it's a lot of work reading all this stuff, to be candid)

Re: some valid domains getting blocked

Posted: September 18th, 2019, 9:27 pm
by axel2078
Blue network? I never configured a blue network. I set it up as just red/green. I do know that if I bypass IPfire straight to the cable modem that everything works, so I’m at a loss as to how to fix this.

As far as ping succeeding, it depends on the domain, but I know that I can’t ping apps.webster.edu from IPfire or from a client on my network, but if I connect my VPN or connect directly to the cable modem, I get successful ping replies.

Re: some valid domains getting blocked

Posted: September 19th, 2019, 6:37 am
by Alorotom
Hello axel2078,

since your IPFire is on VMWare, why not set up a second VM with a straight standard installation based on the current image. Just to check if the problems occure also on that or not. This could narrow it down to your productive VM and it's configuration or to an IPFire problem in general (maybe in a specific constellation).

If you query this bulletin board you'll find some more fellow sufferer. As far as I know, this has never been traced down to the clear reason. As I experienced this behaviour I could at least figure it out as a DNS problem. It did for some reason not resolve the target domain (combination of unbound / DNSSEC / german Telekom DNS). Just now all your provided links resolve fine for me but e.g. https://worldclassroom.webster.edu/login/ldap is not only worldclassroom.webster.de but also minimum four other domains: cloudfront.net, google-analytics.com, gstatic.com and instructure-uploads.s3.amazonaws.com. So if not all of them load correct, the site might time out although you can ping worldclassroom.webster.edu.

This said you could also give a try to configure other DNS Servers for IPFire.

Regards
Alorotom