IRC Logs

Network: freenode Channel: #iptables

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

[18:29]<s19g>very stupid of me (again)
[18:30]<s19g>nat server was using port 5353 for mdns, explicityly permitted by iptables rules.
[18:30]<vyrn-vnzsr>s34n: what was it?
[18:31]<s19g>client was using port 53, not explicitly permitted in iptables rules
[18:32]<vyrn-vnzsr>that will do it, well you're on to your next problem then... ;)
[18:32]<s19g>no. there are absolutely no more problems in my life now
[18:33]<vyrn-vnzsr>s34n: lol, wishful thinking
[18:33]<s19g>I just have to get the ipv6 thing working... ;)
[20:23]<s19g>when the nat server receives replies to NAT'ed requests, at what point in all the chains does it change the destination of the packet?
[20:23]<s19g>before input/output/forward?
[20:24]<s19g>(this is for SNAT)
[20:30]<byffyngdjjn>s34n, after postrouting (nat)
[20:31]<byffyngdjjn>or a little before, its use postrouting to do snat ...
[20:31]<s19g>it uses postrouting when sending the original request
[20:32]<s19g>does it also use postrouting for replies traveling from public to private?
[20:33]<byffyngdjjn>im not 100% sure ... I think you need to see the source code to know it
[20:33]<s19g>ok.
[20:35]<s19g>will --state RELATED,ESTABLISHED -j ACCEPT allow _anything_ to pass back through the NAT as long as the connection was initiated from the inside?
[20:35]<byffyngdjjn>yes
[20:35]<byffyngdjjn>or outside
[20:36]<vyrn-vnzsr>s34n: http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png
[20:36]<vyrn-vnzsr>might be of some use to you
[20:39]<s19g>vice-versa: I guess I'm asking this: For SNAT to work, iptables has to do some DNAT when the packets return... Is that done in the first purple box on the left?
[20:43]<rlraxne>when you create a SNAT rule that will work in both directions
[20:43]<rlraxne>but nat will only alter the sourceip (and to returning traffic the destinationip)
[20:43]<rlraxne>you still need to allow the packet through the FORWARD chain
[20:44]<s19g>Apachez: right. when does it alter the destination ip for returning traffic?
[20:44]<rlraxne>depends on where you have put it
[20:45]<rlraxne>usually its in the -t nat -A POSTROUTING chaing
[20:45]<rlraxne>iptables -t nat -A POSTROUTING -o ${OUTSIDE_DEVICE} -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP}
[20:45]<rlraxne>that is because altering the source address should be the last thing to do
[20:46]<rlraxne>this way only allowed traffic (which already has passed FORWARD) will be altered
[20:46]<rlraxne>otherwise you would alter traffic which might be dropped later on and that way wasting cpu resources
[20:47]<byffyngdjjn>btw, anyone has done a isp redundancy using iptables ?
[20:47]<s19g>I understand that you define SNAT rules in the POSTROUTING chain
[20:48]<byffyngdjjn>for example: I have two isp links, and I want when one goes down, the other assumes, and vice-versa
[20:48]<s19g>my question is whether the reverse operation (the altering of the destination ip for returning packets) also occurs in the POSTROUTING chain
[20:49]<s19g>You don't declare it anywhere. It just happens magically for SNAT rules
[20:49]<s19g>but where in the process does it occur?
[20:52]<vyrn-vnzsr>s34n: POSTROUTING chain is processed last of the chains, the packet will already be DNAT'ed once it reaches that specific chain, exactly where I'm not sure
[20:55]<rlraxne>i think it would be in the postrouting aswell
[20:55]<rlraxne>like routing firewall
[20:55]<s19g>ok
[20:55]<rlraxne>inside -> FORWARD -> POSTROUTING -> outside
[20:55]<rlraxne>(i didnt mention prerouting since you dont have anything regarding to nat there usually)
[20:55]<rlraxne>so returning traffic would be
[20:55]<rlraxne>outside -> FORWARD -> POSTROUTING -> inside
[20:56]<rlraxne>inside -> FORWARD (allow or drop traffic) -> POSTROUTING (alter source ip) -> outside
[20:56]<s19g>so as long as I have |--state RELATED,ESTABLISHED -j ACCEPT| in my input chain, it should allow everything to come back in unfiltered
[20:56]<rlraxne>outside -> FORWARD (allow or drop traffic) -> POSTROUTING (alter destination ip ) -> inside
[20:57]<rlraxne>INPUT chain is only for traffic which goes to local processes on the box
[20:57]<rlraxne>traffic which will pass will go through FORWARD
[20:58]<rlraxne>incoming traffic that will be nated: outside -> PREROUTING -> FORWARD -> POSTROUTING -> inside
[20:58]<rlraxne>incoming traffic to a local service outside -> PREROUTING -> INPUT
[20:59]<rlraxne>there is an ascii art on netfilters page describing the relations between the chains
[21:04]<s19g>Apachez: thank you
[21:05]<s19g>by default, fedora marries the input and forward chains
[21:06]<s19g>my life just got tremendously easier by divorcing them
[21:06]<rlraxne>marries ?
[21:06]<rlraxne>they have altered the kernelcode you mean ?
[21:07]<s19g>no. they set up a chain of their own
[21:07]<s19g>then send both INPUT and FORWARD to that chain
[21:09]<s19g>they set up a chain of their own. then send both INPUT and FORWARD to that chain
[21:10]<s19g>by decoupling them, and leaving the FORWARD chain empty... My NAT should not bother filtering any NAT'ed traffic in either direction.
[21:11]<rlraxne>ahh yes
[21:11]<rlraxne>thats sounds like a bad optimization they did
[21:12]<rlraxne>because input/output traffic is often way different from forward traffic
[21:31]<-- gjmrm9ww_rwrd xrs>http:www.devmatrix.org")
[21:40]<wg2_cgjws>i'm trying to setup a VPN
[21:40]<wg2_cgjws>and trying to do a SNAT
[21:41]<wg2_cgjws>the packet enters the VPN gateway box
[21:41]<wg2_cgjws>where iptables' running
[21:41]<wg2_cgjws>but it seems the packet doesn't reach the POSTROUTING chain
[21:41]<wg2_cgjws>that could make my SNAT works
[21:42]<wg2_cgjws>why the packet doesn't seem to reach the POSTROUTING chain ?
[21:42]<wg2_cgjws>the counters doesn't change
[21:44]<rlraxne>you need to allow the packets in the FORWARD chain
[21:44]<rlraxne>the POSTROUTING will just perform the nat
[21:44]<wg2_cgjws>hmmm
[21:44]<wg2_cgjws>even if FORWARD has ACCEPT policy ?
[21:44]<rlraxne>err
[21:44]<rlraxne>FORWARD or INPUT depending on if you run VPN on a box on the inside network or on this iptables box itself
[21:45]<wg2_cgjws>on this iptables box itself
[21:45]<wg2_cgjws>so, FORWARD :D
[21:46]<wg2_cgjws>Apachez, the counters stay 'zeroed'
[21:47]<wg2_cgjws>my FORWARD, on this box, has ACCEPT policy
[21:48]<rlraxne>no
[21:48]<rlraxne>if its on your iptables box itself where you have the vpn then its in INPUT you should put the allow rules
[21:48]<wg2_cgjws>hmm
[21:48]<rlraxne>something like, assuming your vpn uses udp port 123
[21:49]<rlraxne>iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[21:50]<rlraxne>iptables -A INPUT -p udp -s 0/0 --sport 1024:65535 -d ${OUTSIDE_IP} --dport 113 -m state --state NEW -j ACCEPT
[21:50]<rlraxne>ohh that went udp 113 but anyway :P
[21:59]<wg2_cgjws>Apachez, what if both chains has the policy set ACCEPT ?
[22:00]<rlraxne>then its bad security :P
[22:00]<wg2_cgjws>do i need to accept explicit ?
[22:00]<wg2_cgjws>i know

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