I have a puzzling one.
ClearOS firewall, Dell tower
Debian webserver, separate machine on Dell Poweredge KVM hypervisor; HTTPS, so :443
FreeBSD Nextcloud, separate machine on HP Proliant, internal only, all forwarded via webserver, so port 80
Win10 on custom tower, Plex server at :32400
All outbound seems to be working fine, as well as all inbound on other services allowed (RDP on various non-standard ports, and Plex on 32400. The only thing not working is HTTPS, and it's a bit quirky setup. My ISP uses ports 80 and 443 for internal management, so he forwards those requests to 81 and 444, respectively. I then forward them inside my own network back to 80 and 443. This works fine.
Couple weeks ago I rebooted my firewall, and access to my webserver from outside my network wasn't working. Internally, everything worked fine. I checked my firewall rules, double-checked them, manually entered some in iptables. I had my ISP confirm the settings were all correct on his end...finally I noticed my not-yet-complete openVPN had automatically brought up tun0 and tun1 interfaces; I shut those down and everything worked.
A power glitch Sunday rebooted my firewall because I'm too cheap for battery backups. Same problem. This time stopping openVPN doesn't fix the issue, nor do manually inserting the iptables rules. Everything still works fine internally, and Plex is accessible from outside, it only seems my HTTP/HTTPS/81/444 forwarding isn't working correctly.
ClearOS firewall, Dell tower
Debian webserver, separate machine on Dell Poweredge KVM hypervisor; HTTPS, so :443
FreeBSD Nextcloud, separate machine on HP Proliant, internal only, all forwarded via webserver, so port 80
Win10 on custom tower, Plex server at :32400
All outbound seems to be working fine, as well as all inbound on other services allowed (RDP on various non-standard ports, and Plex on 32400. The only thing not working is HTTPS, and it's a bit quirky setup. My ISP uses ports 80 and 443 for internal management, so he forwards those requests to 81 and 444, respectively. I then forward them inside my own network back to 80 and 443. This works fine.
Couple weeks ago I rebooted my firewall, and access to my webserver from outside my network wasn't working. Internally, everything worked fine. I checked my firewall rules, double-checked them, manually entered some in iptables. I had my ISP confirm the settings were all correct on his end...finally I noticed my not-yet-complete openVPN had automatically brought up tun0 and tun1 interfaces; I shut those down and everything worked.
A power glitch Sunday rebooted my firewall because I'm too cheap for battery backups. Same problem. This time stopping openVPN doesn't fix the issue, nor do manually inserting the iptables rules. Everything still works fine internally, and Plex is accessible from outside, it only seems my HTTP/HTTPS/81/444 forwarding isn't working correctly.
Share this post:
Responses (10)
-
Accepted Answer
Checked tcpdump, and I was seeing outbound 443, and saw plenty of inbound 81 traffic, but nothing on 444 either way. E-mailed my ISP and updated him on the troubleshooting, then we had another power glitch last night (I've never had such unreliable electricity) and everything seems to be working again.
I'll wait to actually hear back from my ISP, and go through a few reboots this weekend to confirm it all stays up, but thanks for your help in confirming things on my end were OK. -
Accepted Answer
Understanding now. he is not a big commercial ISP, just a mini home made one. I guess the next thing to do is set up a packet sniff on your external interface. Something like:
and see if you are receiving anything. Check the line with port 81 first as that is working (I can see your page on port 80).tcpdump -nn -i eth1 port 444 -
Accepted Answer
I don't think you're understanding. He uses port 80 across his network to manage. Therefore, for me to use port 80, it has to be something different; if he calls up my gateway (192.168.100.24) at port 80, he doesn't want that redirected to my webserver, he wants the gateway. Why he chose to use 80 and 443 instead of something different, I don't know. Don't care.
So for me to use port 80, the gateway has to handle it different, he selected port 81. So when something comes to 64.146.227.38:80 (my public address), it gets to his network and routed to 192.168.100.24:81 (because 192.168.100.24:80 is his admin interface). I then take that and redirect it to 10.0.0.250:80 inside my firewall.
He's only redirecting INCOMING traffic to 81 and 443; and only for me (I'm a unique case for him). If I try to go to 192.168.100.24:81, it redirects to my blank Debian Apache holding page.
He only runs the ISP in his spare time (we're pretty rural, and I get essentially symmetrical 60mbps wireless for $40/mo), and it's kind of a one man shop. I think his kid helps him some. So I want to make sure there's nothing goofy on my side before I ask him yet again if it's all good on his side. -
Accepted Answer
I am finding your ISP's story a little hard to believe. If he manages your device on 80 and 443, if he redirects those ports to 81 and 444 then he can't manage his device either (as they then get redirected to you). Do you have to address your site on 81 and 444 externally or 80 and 443? If it is 80 and 443 then his explanation makes no sense. Also I would be really surprised that an ISP has a high speed device that then blocks 80 and 443 to his customers.
Is it worth asking him if he as a bridge mode? Then your WAN will get a public IP and you can forget all forwarding through his device. ClerOS will then become your external firewall. If he can't do that, can he put you in a DMZ? -
Accepted Answer
My gateway isn't under my control, but I'm told the forwards are in place and functioning (81 to 80, 444 to 443).
I accept both HTTP and HTTPS connections and send them to my webserver, which listens for 80 and 443; my server uses a RewriteRule to rewrite everything to https.
My webserver is listening on 443. It works internally and worked until a power glitch rebooted my equipment.
What I'm seeing from your nmap output, is that my firewall is either not forwarding 444, or is not getting it. My server responds correctly internally:
scarint@strix:~$ nmap 10.0.0.250 -p 80,81,443,444
~
Starting Nmap 7.60 ( https://nmap.org ) at 2019-07-20 11:12 PDT
Nmap scan report for 10.0.0.250
Host is up (0.00066s latency).
~
PORT STATE SERVICE
80/tcp open http
81/tcp closed hosts2-ns
443/tcp open https
444/tcp closed snpp
~
Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds
I removed the Rewrite rules on my server, so it should respond on http now. -
Accepted Answer
Is it correct that you have 443 and 80 both going to the same IP? I thought the should be going to different boxes.
On your gateway device are you port forwarding to ClearOS?
Doing an nmap I get:[root@server ~]# nmap ruralprogrammer.com -p 80,81,443,444
Starting Nmap 6.40 ( http://nmap.org ) at 2019-07-20 18:22 BST
Nmap scan report for ruralprogrammer.com (64.146.227.38)
Host is up (0.17s latency).
rDNS record for 64.146.227.38: ip-64-146-227-38.noanet.net
PORT STATE SERVICE
80/tcp open http
81/tcp open hosts2-ns
443/tcp closed https
444/tcp closed snpp
Nmap done: 1 IP address (1 host up) scanned in 2.15 seconds
Somewhere you have a redirect. If I go to http://ruralprogrammer.com:81 it ends up being redirected to https://ruralprogrammer.com/ and you have noting listening on 443, so you may have a few internal issues. If the redirect is a permanent one, you'll have to tell your browser to forget about your site before trying again.
You may also want to try tcpdump to check where the packets are going. -
Accepted Answer
This is just my current iteration (the reboot before posting my iptables was to clean up all the hacked together rules I've been trying) I've tried everything you've mentioned, except the proxypass. I'm using proxypass on my webserver to forward to my nextcloud server, so don't want to get too many of those going.
In the past, I assumed I needed to open the incoming port and forward, and it's never caused any hiccups for me. From what I've been reading lately, the port forward will override the incoming, so it *shoud* be fine, but best practice is to put it in only one place. I've still been testing both ways.
Just to double-check things and because arguing isn't worth it, I removed 80, 81, 443, and 444 from incoming, and removed the 443->443 and 80 -> 80 forwarding rules, so I only have 444 -> 443 and 81 -> 80. I also cleaned up all my unnecessary RDP, XBox, Spiceworks, and unused E-mail ports from Incoming. I also went ahead and removed the drop rules from the FORWARD chain (pretty sure I figured out what they were for). My new iptables below, and still cannot access my webserver from outside (ruralprogrammer.com, if you're interested in checking). I'm starting to wonder if my ISP was lying to me about something getting changed on his end, and quietly fixed it just as I was troubleshooting last time.
Plex is still accessible through the Plex app, but not if I navigate directly (ruralprogrammer.com:32400), though I don't know if that ever worked.
[root@firewall ~]# iptables -nvL
Chain INPUT (policy DROP 56 packets, 3990 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- eth1 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- eth1 * 169.254.0.0/16 0.0.0.0/0
151 20052 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
345 42624 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
2 58 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:1194
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:4172
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:1194
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:2345
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:26790
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:26790
0 0 ACCEPT 47 -- * * 0.0.0.0/0 192.168.100.24
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:1723
9 1319 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
41 46719 ACCEPT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.250 tcp dpt:443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.250 tcp dpt:80
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.253 tcp dpt:32400
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 10.0.0.253 udp dpt:32400
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.251 tcp dpt:26790
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 10.0.0.251 udp dpt:26790
80 19713 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
7 490 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
151 20052 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * pptp+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
184 33948 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0
2 58 ACCEPT icmp -- * eth1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * eth1 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth1 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:1194
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:4172
0 0 ACCEPT udp -- * eth1 192.168.100.24 0.0.0.0/0 udp spt:1194
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:2345
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:26790
0 0 ACCEPT udp -- * eth1 192.168.100.24 0.0.0.0/0 udp spt:26790
0 0 ACCEPT 47 -- * eth1 192.168.100.24 0.0.0.0/0
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:1723
92 10865 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain DROP-lan (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
[root@firewall ~]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 598 packets, 56022 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:444 to:10.0.0.250:443
12 576 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:81 to:10.0.0.250:80
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:32400 to:10.0.0.253:32400
0 0 DNAT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:32400 to:10.0.0.253:32400
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:26790 to:10.0.0.251:26790
0 0 DNAT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:26790 to:10.0.0.251:26790
Chain POSTROUTING (policy ACCEPT 114 packets, 19289 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.250 tcp dpt:443 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.250 tcp dpt:80 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.253 tcp dpt:32400 to:10.0.0.1
0 0 SNAT udp -- * * 10.0.0.0/8 10.0.0.253 udp dpt:32400 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.251 tcp dpt:26790 to:10.0.0.1
0 0 SNAT udp -- * * 10.0.0.0/8 10.0.0.251 udp dpt:26790 to:10.0.0.1
551 48629 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 82 packets, 19292 bytes)
pkts bytes target prot opt in out source destination -
Accepted Answer
I think your rules are slightly all over the place. If you have a port forward, you must not open the same incoming port. You've opened and forwarded at least 80,81,443 and 444. It is one or the other.
Then in your forwarding you also have funny rules as you have one rule switching 443 to 444 and one forwarding 443 to 443. It is the same for 80 and 81.
I think you can remove your port forwards of 80 to 80 and 443 to 443 and close the incoming 80,81, 443 and 444.
If you were really cute, you may be able to use the ProxyPass app on ClearOS to forward web traffic to your two other machines., but you'd need to think carefully about the use of port 81 as it is also used by the webconfig with https. -
Accepted Answer
Not a problem. Didn't post it earlier because a friend was streaming from my Plex server.
192.168.100.24 is my firewall's address from my ISP. 64.146.227.38 is my public address. And like I said, 443 gets forwarded to 444 (snpp in iptables) and I forward that to 10.0.0.250:443. My Plex forwarding (32400) and torrent seedbox (26790) work fine, and this whole setup has worked fine for months.
I removed my RDP, ssh, and other fowards such as those. I'm not sure why I'm blocking outbound to all the AWS servers, but I figure I had a good reason whenever I did that.
[root@firewall ~]# iptables -nvL
Chain INPUT (policy DROP 199 packets, 18909 bytes)
pkts bytes target prot opt in out source destination
43 3640 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
60 12185 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- eth1 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- eth1 * 169.254.0.0/16 0.0.0.0/0
1041 523K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
705 119K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
6 174 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 0
2 172 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:8080
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:143
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:1494
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:587
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:995
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:443
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:444
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:81
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:1194
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:4172
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:32400
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:32400
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:1434
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:88
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:8444
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:9675
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:3074
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:3074
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:1194
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:2345
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:26790
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:26790
0 0 ACCEPT 47 -- * * 0.0.0.0/0 192.168.100.24
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:1723
149 26978 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
1110 1264K ACCEPT tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2 112 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.250 tcp dpt:80
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.250 tcp dpt:443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.250 tcp dpt:443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.250 tcp dpt:80
2 142 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.253 tcp dpt:32400
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 10.0.0.253 udp dpt:32400
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.0.0.251 tcp dpt:26790
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 10.0.0.251 udp dpt:26790
0 0 DROP all -- * * 10.0.0.0/8 192.150.19.55
0 0 DROP all -- * * 10.0.0.0/8 52.204.134.200
0 0 DROP all -- * * 10.0.0.0/8 52.0.123.66
0 0 DROP all -- * * 10.0.0.0/8 50.17.109.157
0 0 DROP all -- * * 10.0.0.0/8 52.201.100.21
0 0 DROP all -- * * 10.0.0.0/8 52.203.176.204
0 0 DROP all -- * * 10.0.0.0/8 52.0.118.108
0 0 DROP all -- * * 10.0.0.0/8 52.203.241.15
0 0 DROP all -- * * 10.0.0.0/8 52.2.148.244
0 0 DROP all -- * * 10.0.0.0/8 54.209.22.103
0 0 DROP all -- * * 10.0.0.0/8 54.208.106.222
0 0 DROP all -- * * 10.0.0.0/8 54.174.187.14
0 0 DROP all -- * * 10.0.0.0/8 192.150.14.173
0 0 DROP all -- * * 10.0.0.0/8 34.204.211.142
0 0 DROP all -- * * 10.0.0.0/8 52.72.122.176
16228 2916K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1446 137K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1041 523K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * pptp+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
381 59185 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0
6 174 ACCEPT icmp -- * eth1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * eth1 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth1 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:8080
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:143
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:1494
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:587
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:995
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:80
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:443
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:444
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:81
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:1194
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:4172
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:32400
0 0 ACCEPT udp -- * eth1 192.168.100.24 0.0.0.0/0 udp spt:32400
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:1434
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:88
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:8444
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:9675
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:3074
0 0 ACCEPT udp -- * eth1 192.168.100.24 0.0.0.0/0 udp spt:3074
0 0 ACCEPT udp -- * eth1 192.168.100.24 0.0.0.0/0 udp spt:1194
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:2345
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:26790
0 0 ACCEPT udp -- * eth1 192.168.100.24 0.0.0.0/0 udp spt:26790
0 0 ACCEPT 47 -- * eth1 192.168.100.24 0.0.0.0/0
0 0 ACCEPT tcp -- * eth1 192.168.100.24 0.0.0.0/0 tcp spt:1723
1479 187K ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain DROP-lan (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
[root@firewall ~]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1683 packets, 169K bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:80 to:10.0.0.250:80
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:443 to:10.0.0.250:443
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:444 to:10.0.0.250:443
1 60 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:81 to:10.0.0.250:80
2 142 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:32400 to:10.0.0.253:32400
0 0 DNAT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:32400 to:10.0.0.253:32400
0 0 DNAT tcp -- * * 0.0.0.0/0 192.168.100.24 tcp dpt:26790 to:10.0.0.251:26790
0 0 DNAT udp -- * * 0.0.0.0/0 192.168.100.24 udp dpt:26790 to:10.0.0.251:26790
Chain POSTROUTING (policy ACCEPT 416 packets, 43773 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.250 tcp dpt:80 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.250 tcp dpt:443 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.250 tcp dpt:443 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.250 tcp dpt:80 to:10.0.0.1
4 240 SNAT tcp -- * * 10.0.0.0/8 10.0.0.253 tcp dpt:32400 to:10.0.0.1
0 0 SNAT udp -- * * 10.0.0.0/8 10.0.0.253 udp dpt:32400 to:10.0.0.1
0 0 SNAT tcp -- * * 10.0.0.0/8 10.0.0.251 tcp dpt:26790 to:10.0.0.1
0 0 SNAT udp -- * * 10.0.0.0/8 10.0.0.251 udp dpt:26790 to:10.0.0.1
1688 150K MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 361 packets, 49360 bytes)
pkts bytes target prot opt in out source destination -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »