IRC Logs

Network: freenode Channel: #iptables

	Enter your search terms Submit search form
	Web www.irclog.org

[00:01]<wjjmmwjjmlnacnz>mangle postrouting -> nat postrouting
[00:02]<wjjmmwjjmlnacnz>Nat postrouting is the last of all chains, if you don't count with Qdisc's
[00:18]<mzmzjzax>WoodyWoodpecker: Thanks.
[00:19]<wjjmmwjjmlnacnz>madroach: np
[00:23]<affy2zn>repasting this question here..
[00:23]<affy2zn>What are some ways to clear out the ip_conntrack table?
[00:23]<affy2zn>I can send RST packets to the tuples in question, but that seems kind of brute force to me
[00:23]<affy2zn>It also is not really that big a deal to have 5000 entries in there, but I would like to clear it out from time to time (only 350 bytes per entry, not a big deal when you have 4gb on the firewall in question
[00:27]<wjjmmwjjmlnacnz>jplibre: Somewhere in /proc/sy/net/ipv4/ . Find the right one and echo "0" > /proc/...
[00:28]<affy2zn>you mean set the max temporarily to zero?
[00:28]<affy2zn>ouch
[00:28]<affy2zn>but I guess that works :P
[00:29]<affy2zn>actually it doesn't, would need to reload the module
[00:30]<affy2zn>and I think reloading the module zeroes it out anyway?
[00:32]<affy2zn>wow, even if I set ip_conntrack_max to 0 and restart the network interfaces it doesn't clear the table
[00:33]<affy2zn>must have to reload the ip_conntrack module entirely to read that value
[00:33]<affy2zn>which would have to be done when the interfaces are down
[00:37]<vfrmmd>what version of iptables is needed for x_tables support?
[00:51]<affy2zn>not such an active channel :)
[00:54]<zj2wow0>Vladdy: iirc (and I may not), that's actually a change on the netfilter (kernel) side of things, and occurred with 2.6.16
[00:57]<vfrmmd>it is, but now iptables won't autoload the required modules any more, so I'm curious if there is a version of iptables where that is fixed ;-)
[00:59]<zj2wow0>Vladdy: well, do the modules exist? Where did you get the new kernel? If you compiled it yourself, did you add the x_tables support? Some modules were renamed with 2.6.16 (and some with 2.6.17 too iirc)
[00:59]<zj2wow0>Too many variables here...
[01:00]<vfrmmd>actually, it's a homebrew kernel, but it's broken right now anyway since it fails to get networking working ;p
[01:01]<zj2wow0>If you've been force-loading modules for iptables, some of the names have changed, so that may be part of the problem...
[01:01]<zj2wow0>Anyway, I must go - good luck!
[01:02]<vfrmmd>thanks :)
[01:03]<vfrmmd>well, on older kernels I didn't have to load any module, but now I do :(
[01:45]<-- sgvgzs xzs fuyv (>/dev/brain")
[02:04]<mrvv>hi guys
[02:04]<mrvv>I have a slightly messy setup to workround
[02:05]<mrvv>involving a multi-homed server and a vpn device that's got a broken implementation
[02:05]<mrvv>server has two nics, eth0 is external, eth1 is internal; vpn box has the same
[02:06]<mrvv>when a user VPNs in, traffic over the VPN to the local network is decrypted by the vpn box and injected into the local network *with the original (internet based) source IP*
[02:06]<mrvv>the vpn box then relies on the fact that internal machines will be using it as a default route in order to get the reply packets to encrypt and send back to the client
[02:10]<mrvv>obviously that's going to cause problems when people try to hit the server, cause it sees packets with an external source address on the internal interface; so by default, routing will send the reply packets back out the external interface, which means they never get back to the vpn box to be encrypted and sent back to the client
[02:10]<mrvv>I'm wondering if we can do something funky with iptables
[02:11]<mrvv>like SNAT packets arriving with an external address on eth1 to a given internal address, then DNAT the outbound replies to the external address after processing a routing decision to send them to the internal address of the vpn box as the next hop
[02:12]<mrvv>so my question is - is that possible :&)
[02:23]<bfyssnwq>Matt: looks like your setup is sort of wrong. More than fixable with 'iptables'.
[02:24]<bfyssnwq>Matt: in particular I suspect that your routing is sort not quite right.
[02:48]<mrvv>it's the vpn device that's buggered
[02:48]<mrvv>it completely screws the whole thing up
[02:51]<mrvv>and that I don't have any control over :&/
[04:15]<gmmugmj_v>hello
[04:16]<gmmugmj_v>does anyone knows if its normal to put a default policy of drop on nat and mangle tables?
[04:16]<mrrynfmr>no
[04:17]<mrrynfmr>only default drop on filter
[04:18]<gmmugmj_v>I bought the book "Linux Firewalls, 3rd Edition" from Novel Press, and it has examples with drop policies in all tables
[04:18]<gmmugmj_v>I didnt found any errata
[04:19]<gmmugmj_v>these examples freezes the firewall :)
[04:19]<mrrynfmr>what other rules did they have?
[04:20]<gmmugmj_v>only rules allow traffic on the filter table
[04:20]<gmmugmj_v>I was looking at some diagrams of packet paths, and they even pass through the mangle table
[04:20]<mrrynfmr>sounds like a stupid mistake
[04:20]<gmmugmj_v>so they its blocked before beeing accepted
[04:21]<mrrynfmr>cj: maxine's gone again
[04:23]<gmmugmj_v>yep, as you can see the packets pass first through mangle table (prerouting chain) before beeing accepted by the input chain in the filter table
[04:23]<mrrynfmr>yes
[04:24]<mrrynfmr>tell that to the authors of the book :)
[04:24]<gmmugmj_v>it sounds very stupid, to make it work that way whould be necessary three rules for each "accept"
[04:25]<gmmugmj_v>any other version worked different?
[04:25]<gmmugmj_v>ipchains maybe?
[04:25]<mrrynfmr>hmm? other version?
[04:26]<mrrynfmr>oh. I've never used ipchains, so not sure. I don't think so, however
[04:26]<mrrynfmr>kernel 2.2 has been obsolete for a while
[04:28]<gmmugmj_v>at least it shows how to debug that bullshit
[04:45]<gmmugmj_v>danieldg, in that diagram local traffic and routed traffic are not differentiated
[04:45]<mrrynfmr>yes they are...
[04:45]<gmmugmj_v>nat tables are traversed by all packets?
[04:45]<mrrynfmr>yes
[04:46]<mrrynfmr>the differentiation is after PREROUTING
[04:48]<gmmugmj_v>QOS is a service like shaper?
[04:48]<mrrynfmr>yes
[04:49]<mrrynfmr>that box should also say "routing decision"
[04:50]<mrrynfmr>a bit more detailed diagram, if you wanted it: http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
[05:31]<svnvnn61>hello. i just did a huge upgrade on my gentoo box, and I can't get from the lan to the internet
[05:32]<svnvnn61>routing or something got screwed
[05:33]<svnvnn61>can anybody give me a heads up? not sure how to troubleshoot
[05:34]<gmmugmj_v>how did you configured the firewall before?
[05:35]<svnvnn61>with an input file
[05:35]<svnvnn61>i did iptables-save and it looks ok
[05:38]<gmmugmj_v>and loading it back doesnt work?
[05:40]<svnvnn61>the problem was ip_forward
[05:42]<svnvnn61>gotta reboot unless i can make that take effect some other way.
[05:43]<svnvnn61>nah i got it now
[07:40]<-- gjmrm9ww xrs fuyv>http:www.devmatrix.org")
[08:27]<-- sgvgzs xzs fuyv (>/dev/brain")
[09:48]<scrgn>i said accidently iptables -F
[09:48]<scrgn>default policy in all chains was "drop"
[09:48]<scrgn>does this mean i am locked ouot?

Back to #iptables
Or go to some related logs:
#blender
#python
#suse
#blender
#php