Already a couple of times I received great help in the past which directed my to solutions.
That is among other reasons what AlmaLinux makes special. The forum and community.
This time I want to ask some help with a httpd server setup on almalinux:
Sometimes you think to install something quickly, but in the end a system hangs and it seems to be something impossible. Manuals on the net don’t help, or you’re searching the wrong keywords. This is what i have now.
I wanted to activate my fresh installed apache server to receive incoming traffic on 443 from outside on the WAN.
Using Apache which is called httpd package in centos and almalinux terms.
I did the selinux thing, the firewalld zone=public =>
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
I have setsebool on permissive mode, to avoid it is hanging there.
Also I did: setsebool -P httpd_can_network_connect=1
(unneeded but still…)
The problem:
From within the LAN, the server responds by sending the content to the client browser.
But now the weird part, I configured my home router to forward 443 https port and 80 http port to the servers LAN ip. It shows a green bullet on the routers webportal page, which indicates the forwarded port is active.
Unfortunately I can’t have a reply when I try to enter from the routers public internet ip to test my forwarded port. How to test where the route is getting blocked on the way?
Thanks for any hints. Probably I forgot some critical details to describe the situation, sorry for that if so.
I do usually listen with tcpdump when traffic should happen.
Something like: tcpdump -vv -nn port 443
It should show connection attempts (to https) from other LAN machines (positive control) and also from outside. If the latter shows no packets, then the router does not forward correctly. If packets come in, but no reply packets, then something in your machine, etc.
Thanks, handy command, it seems to give direct hits on the interface listening for each interface . I found this alternative:
tcpdump -i {interface] -vv -nn port 80
is possible to.
For example: tcpdump -i eno -vv -nn port 80
This way it is possible to see which interface responds on incoming traffic on the 80 port.
However, this gives more questions. See, I didn’t mention I run a vpn client on this machine to simplify the scenario to explain.
It seems now, the tcpdump -vv -nn port 443
command shows that the machine only listens to tun0.
( If I run default tcpdump -vv -nn port 80, it gives:
tcpdump: listening on tun0 )
This makes things complex. OK i need to think about that.
Thanks for the hint.
I forgot/omitted the -i [interface] option, but yes you probably should use it since you have more than one interface. (The tcpdump defaults to one interface and not always to the one we are interested in.)
It can narrow down what is matched. Now the filter was “port N” (regardless of protocol), but there could be also “host Y” (in either source or destination), network, etc.
VPN … depends how it is done. Generally, VPN application communicates over the “regular network” and what traffic is there is encrypted packages to/from VPN ports. The actual “payload” is hidden inside.
The “tun0” is probably virtual interface created by the VPN. When you send a packet via tun0, it could be HTTP, SSH, or whatever you send and tcpdump that listens on tun0 would see it as such. At the same time the VPN application will send “VPN packet” via physical interface (that tcpdump on that interface would see).
[EDIT] You have a VPN tunnel between this Alma and somebody “out there”?
And your router forwards other traffic to this Alma?
The router would forward to the physical interface of Alma. When the httpd sends a reply, is it routed via physical interface (towards the router), or via the VPN tunnel to who-knows-where? If the latter, the other end of your VPN tunnel would forward the reply to you. But you never did send HTTP request to that machine …