Bastille/netfilter with Linux 2.6.28 blocks connections
Quoted 1 line
Hi!
Hi,
Quoted 1 line
Why you said "now". It has never worked? When it's start to had problems?
It has worked on earlier days and with an older kernel, I cannot recall the exact version number, so maybe it was 2.6.18 which I have also used a long time. But once I have upgraded it to newer kernels, and double-checked the config, these routing problems starts.
Okay, anyway. As I have promised before I have uploaded some more details:
First here is the requested logfile (syslog) with the relevant ports:
http://www.mxchange.org/downloads/firebox/tor-drops_syslog.log
Okay, two thinks I was mentioning before where wrong, sorry about that. :( First INPUT DROP 8 is dropping the packets and second they came from outside as you can see in the logs.
Here are some more files for inspection:
My actually used kernel config:
http://www.mxchange.org/downloads/firebox/config-2.6.28-vanilla
Output of "route -n": (it should be fine, I suppose)
http://www.mxchange.org/downloads/firebox/route.txt
That x.x.x.x was me. It is the PPP partner IP of my ISP.
This directory contains my extra-scripts for the corresponding Bastille "hooks":
http://www.mxchange.org/downloads/firebox/firewall.d/
That directory should be found in /etc/Bastille/.
Quoted 4 lines
You have to say us what you want to leave pass from that firewall... tor from internet, from lan? tor on localhost wants to connect to your-self by 127 or 192 ?
192.168.1.1 is my router, 192.168.1.1x are my clients, both have a "default gateway" set to 192.168.1.1 and /etc/resolve.conf has a nameserver entry pointing only to 192.168.1.1
I want to pass through from my LAN (eth1) to Internet (eth0/ppp0) regular things like Mail, Newsgroups and such things. So I need to masq my private network 192.168.1.0 on eth1 to the Internet. And this is no longer working.
I want to route traffic from Internet on TCP/UDP port 31017 which is being used by Descent2-Rebirth to my client 192.168.1.17. I used PREROUTE and FORWARD for this.
Like I wrote above it *has* worked, until I have upgraded the farly outdated kernel which should be done on regular basis. I guess you know why. :)
Quoted 1 line
Too short description and no logs.
Hope that helps a bit more? :)
Roland
__________________________________________________________________
Deutschlands größte Online-Videothek schenkt Ihnen 12.000 Videos!*
http://entertainment.web.de/de/entertainment/maxdome/index.html
Quoted 2 lines · Roland Häder
192.168.1.1 is my router, 192.168.1.1x are my clients, both have a "default gateway" set to 192.168.1.1 and
/etc/resolve.confhas a nameserver entry pointing only to 192.168.1.1
Not right that "both" have the default gw to 192.168.1.1 Only the clients on 192.168.1.0/24 have to. The router (the server where you are writing the iptables rules) need another gw!
Quoted 3 lines
I want to pass through from my LAN (eth1) to Internet (eth0/ppp0) regular things like Mail, Newsgroups and such things. So I need to masq my private network 192.168.1.0 on eth1 to the Internet. And this
is no longer working.
Seen the rules, this must work.
Try
IP -F -t nat
IP -F FORWARD
IP -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
IP -A FORWARD -i eth1 -m state --state NEW -j LOG --log-prefix "NEW FW" IP -A FORWARD -i eth1 -j ACCEPT
IP -A POSTROUTING -o eth0 -m state --state NEW -j LOG --log-prefix "NEW POR" IP -A POSTROUTING -o eth0 -j MASQUERADE
Quoted 2 lines
I want to route traffic from Internet on TCP/UDP port 31017 which is being used by Descent2-Rebirth to my client 192.168.1.17. I used PREROUTE and FORWARD for this.
For this into the above iptables.list there are no rules!
IP -A PREROUTING -i eth0 -p tcp --dport 30017 -j DNAT --to-destination 192.168.1.17
and add the forward one
Quoted 2 lines
Like I wrote above it *has* worked, until I have upgraded the farly outdated kernel which should be done on regular basis. I guess you know why. :)
I don't know about this....
Michele
Quoted 4 lines · Roland Häder
First here is the requested logfile (syslog) with the relevant ports:
http://www.mxchange.org/downloads/firebox/tor-drops_syslog.logOkay, two thinks I was mentioning before where wrong, sorry about that. :( First INPUT DROP 8 is dropping the packets and second they came from outside as you can see in the logs
Hello,
in iptables-save output you supplied:
http://www.mxchange.org/downloads/firebox/iptables.list
there is no 'INPUT DROP 8' rule.
greets
Mart