I cannot access my web server from the outside

Security Firewall Rules
1

Good morning all,
I’m new to IpFire :slight_smile:
there I just installed the said IpFire on a machine with two Red + Green ifaces
in the Green network I have an apache web server, I want it to respond to ports 80.
I added a rule: source all> Nat: destination> Destination: Ip green from the web server> Protocol: TCP and destination port: 80

result:
when I access from a local machine with the green proxy it works
on the contrary when I go out of the network I have a time out

i really want help: sunny:

And thank you in advance!

2

Hi @brahimelysalem

Welcome to the IPFire community.

Please post in English only. We want to be as inclusive as possible to people from everywhere in the world and the de-facto language in Open Source projects is English.

See the IPFire community FAQ for more details.

https://community.ipfire.org/faq

1 Like
3

ok i translate my poste
:slight_smile:

1 Like
4

did you push the button “apply change”?

Screenshot 2021-07-13 at 17.02.40
Screenshot 2021-07-13 at 17.02.402076×590 78.3 KB

Also, are you sure that the machine running the web server is not blocking the traffic from the wan interface on the port 80?

3 Likes
5

yes i pushed the button

image
image874×331 6.34 KB

and the web server has only one iface in green network

it is under centos7 apache2.4 and for now i stoped firewalld

thnx

6

What about the DNS? Are you using one, or are you connecting directly to the public IP of your network? If the former is the case, is the DNS correctly resolving the public IP?

7

My dns is correct
i can acces to my ipfire from web GUI from green and red and by greenIP:444 and redip:444 and domain_name:444

so my DNS is correct and my rule for IpFire access is correct only web access not work

8

I can’t think of anything else. You need to look at the logs. I would connect to your ipfire firewall with ssh, and issue a tail -f (ctrl-c to exit) command to look at the kernel logs in real time, then I would try to connect to the web server and see what happens. For reference, when I do this for my web server (port 443, in the orange network), this is what I see:

tail -f /var/log/messages
[...]
Jul 13 18:32:21 ipfire kernel: DNAT IN=red0 OUT= MAC=00:0d:b9:42:68:92:1c:df:0f:0b:52:ff:08:00 SRC=[redacted] DST=[redacted]LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=4267 DF PROTO=TCP SPT=54592 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 
Jul 13 18:32:21 ipfire kernel: FORWARDFW IN=red0 OUT=orange0 MAC=00:0d:b9:42:68:92:1c:df:0f:0b:52:ff:08:00 SRC=[redacted] DST=10.1.2.100 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=4267 DF PROTO=TCP SPT=54592 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
1 Like
9 
Jul 13 16:38:58 mourabit kernel: DNAT IN=red0 OUT= MAC=c8:d9:d2:31:93:6b:cc:cc:81:74:ac:69:08:00 SRC=[redacted] DST=[redacted] LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=1188 DF PROTO=TCP SPT=61904 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
Jul 13 16:38:58 mourabit kernel: FORWARDFW IN=red0 OUT=green0 MAC=c8:d9:d2:31:93:6b:cc:cc:81:74:ac:69:08:00 SRC=[redacted] DST=192.168.1.178 LEN=52 TOS=0x00 PREC=0x00 TTL=125 ID=1188 DF PROTO=TCP SPT=61904 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
10

Hi,

this seems like at least the SYN packet made it through your IPFire.

Could you have a look at the interface of your web server (perhaps by using tcpdump) and check if the packet really arrives there, and if the web server is correctly sending a SYN+ACK back to the source IP address?

Thanks, and best regards,
Peter Müller

11

tcpdump -i any -s 0 -A 'tcp dst port 80'

12:47:21.125528 IP 192.168.1.178.https > [SRC-IP].42375: Flags [S.], seq 1463307245, ack 3611587619, win 28960, options [mss 1460,sackOK,TS val 754653362 ecr 434122721,nop,wscale 7], length 0

i think that package arrive in my web server
thnx

12 
[root@localhost ~]# tcpdump -i any -s 0 -A 'tcp dst port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:14:55.740301 IP [Client-IP(Source)].31741 > localhost.localdomain.http: Flags [S], seq 354401281, win 64240, options [mss 1400,sackOK,TS val 435808208 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P...................x...
............................
13:14:56.014190 IP [Client-IP(Source)].31742 > localhost.localdomain.http: Flags [S], seq 629051900, win 64240, options [mss 1400,sackOK,TS val 435808458 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P%~.................x...
............................
13:14:56.705451 IP [Client-IP(Source)].31741 > localhost.localdomain.http: Flags [S], seq 354401281, win 64240, options [mss 1400,sackOK,TS val 435809217 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P...................x...
............................
13:14:56.984087 IP [Client-IP(Source)].31742 > localhost.localdomain.http: Flags [S], seq 629051900, win 64240, options [mss 1400,sackOK,TS val 435809473 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P%~.................x...
............................
13:14:58.736655 IP [Client-IP(Source)].31741 > localhost.localdomain.http: Flags [S], seq 354401281, win 64240, options [mss 1400,sackOK,TS val 435811233 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P...................x...
............................
13:14:59.274828 IP [Client-IP(Source)].31742 > localhost.localdomain.http: Flags [S], seq 629051900, win 64240, options [mss 1400,sackOK,TS val 435811489 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P%~.................x...
............................
13:15:03.007564 IP [Client-IP(Source)].31741 > localhost.localdomain.http: Flags [S], seq 354401281, win 64240, options [mss 1400,sackOK,TS val 435815393 ecr 0,nop,wscale 7], length 0
E..<..@.:...).C#....{..P...................x...
............................
13:15:03.155991 IP [Client-IP(Source)].31742 > localhost.localdomain.http: Flags [S], seq 629051900, win 64240, options [mss 1400,sackOK,TS val 435815649 ecr 0,nop,wscale 7], length 0
13

Hi,

thank you for your replies.

We can now confirm a TCP SYN packet to make it from the internet to the interface of your webserver. My guess is the reply (SYN+ACK) not making it back. Perhaps the webserver is missing a default gateway, or something else goes wrong here.

May I ask you to run

tcpdump -i green0 -n host [IP address of your webserver]

on the IPFire machine, try again to reach the webserver from the outside, and report back what appears in the tcpdump output then? In addition, does a ping command to any public IP address on the webserver work?

Thanks, and best regards,
Peter Müller

1 Like