IRC Logs

Network: freenode Channel: #iptables

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

[18:02]<rlraxne>Will I need an explicit "iptables -A BLACKLIST -j RETURN" in the end of the BLACKLIST chain ?
[18:02]<rlraxne>or is it just best practise to always have one in the end ?
[18:17]<rlraxne>is it possible to use --dport or --sport alone without -p tcp or -p udp ?
[18:37]<vzrllysv>Apachez: no. if you don't specify a protocol, it assumes 'all', and not all protocols have ports.
[19:15]<rlraxne>here we go.. seems to be working :) http://www.sqlpaste.com/?entry_id=1419
[19:47]<rlraxne>http://youtube.com/watch?v=DClkE64nFDY&feature=Views&page=1&t=t&f=b
[19:48]<vyrn-vnzsr>Apachez: RESERVED might have been a more descriptive name choice for the custom chain though ;)
[19:50]<rlraxne>bah :P
[19:50]<vyrn-vnzsr>hehe
[20:10]<sxzjvvd>hey
[20:18]<snnfn_>please help .... when I load this rules (http://pastebin.ca/88199) and make ping to lan internal address the ping works .... but when I try the ping with this firewall (http://pastebin.ca/88198) the ping no works
[20:27]<wg2_cgjws>how can I avoid a packet (based on source/dest address or dest port) to hit a MASQUERADE rule in a chain, like POSTROUTING ?
[20:27]<wg2_cgjws>i used to use the RETURN target for it, placing the rule before the rule containing the MASQUERADE target
[20:27]<wg2_cgjws>but, i don't know why, it's not working anymore
[20:28]<rlraxne>could give example of the packet ?
[20:28]<wg2_cgjws>(this last phrase isn't that informative)
[20:28]<wg2_cgjws>:P
[20:28]<wg2_cgjws>hmm
[20:28]<rlraxne>since the masq thingy (either if its masq or through s/dnat (s/dnat is for static ip)) will always occur on the outgoing packets
[20:32]<wg2_cgjws>Apachez, the packet is coming from a host (10.10.10.100) and it's passing through a firewall (10.10.100.1)
[20:33]<wg2_cgjws>this firewall is routing this packet to go through the eth0 interface
[20:33]<wg2_cgjws>(the packet entered by the eth1 interface)
[20:34]<wg2_cgjws>the eth0's firewall IP address is 172.100.100.1
[20:34]<wg2_cgjws>and the packet coming from that host (10.10.10.100) is getting this IP (172.100.100.1) on his header
[20:35]<wg2_cgjws>when routed through eth0
[20:35]<wg2_cgjws>--
[20:35]<wg2_cgjws>did i make myself clear ?
[20:35]<wg2_cgjws>hope so :)
[20:39]<rlraxne>yup
[20:39]<rlraxne>and you dont want it to ?
[20:39]<rlraxne>it should pass unaltered ?
[20:39]<rlraxne>something like
[20:39]<rlraxne>iptables -t nat -A POSTROUTING -o ${OUTSIDE_DEVICE} -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP}
[20:40]<rlraxne>along with a routing entry which forces the packet to jump
[20:40]<rlraxne>and perhaps a rule for FORWARD which allows the explicit ip/range to leave the outside device
[20:41]<wg2_cgjws>Apachez, yes, i'd like to don't have that packet masked
[20:43]<wg2_cgjws>Apachez, but a rule with RETURN target, before the rule with the MASQ target, shouldn't work ?
[20:43]<rlraxne>dunno
[20:43]<rlraxne>you still need to allow the packet to leave the box
[20:43]<rlraxne>the routing entry will make sure that it will be able to route the packet
[20:44]<rlraxne>but then you need a rule in the FORWARD chain which allows the packet to leave the box
[20:44]<rlraxne>or something like -A FORWARD -i INSIDE_DEV -s 10.10.10.100/32 -j ACCEPT
[21:22]<wg2_cgjws>5/2
[21:22]<wg2_cgjws>typo
[21:23]<vyrn-vnzsr>?
[22:35]<s19g>I'm still stumped on why my SNAT isn't working
[22:36]<s19g>ipv4.ip_forward is 1
[22:37]<s19g>Regit was very helpful yesterday, but I'm still missing something
[22:50]<ljsv-bjd>hi
[22:52]<s19g>From the provate side of the nat, I can ping the private interface and the public interface
[22:53]<s19g>but I can't ping the next hop on the public net
[22:53]<s19g>I see the packets come in on the private interface...
[22:53]<s19g>but nothing after that
[22:54]<-- dvxn|syzzzyus xzs>http://www.bagdadsoftware.de")
[22:55]<wg2_cgjws>vice-versa, writing error :)
[22:55]<wg2_cgjws>up there ^^
[22:56]<s19g>web_knows: ?
[23:01]<vyrn-vnzsr>s34n: and the pings work as expected on the NATing box?
[23:01]<s19g>vice-versa: yes
[23:04]<vyrn-vnzsr>s34n: pastebin the output of iptables-save -c
[23:07]<s19g>vice-versa: http://www.rafb.net/paste/results/E237YQ54.html
[23:16]<vyrn-vnzsr>s34n: I would say it's getting dropped in your forward chain, try iptables -nvL FORWARD then try ping then iptables -nvL FORWARD again and compare the counters
[23:17]<s19g>I remove all iptables rules except nat and still had this problem
[23:17]<vyrn-vnzsr>aye
[23:18]<s19g>packets went from 5 to 9
[23:18]<s19g>bytes: 295 -> 535
[23:19]<vyrn-vnzsr>on what rule?
[23:19]<s19g>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
[23:19]<s19g> pkts bytes target prot opt in out source destination
[23:19]<s19g> 9 535 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
[23:22]<vyrn-vnzsr>s34n: try just one POSTROUTING rule with no -p
[23:23]<s19g>k
[23:24]<s19g>doh!
[23:24]<s19g>I knew it would be something simple
[23:24]<vyrn-vnzsr>:)
[23:24]<vyrn-vnzsr>I should have seen it sooner
[23:25]<s19g>I'm going to write a book about how to make even the most simple thing complicated
[23:26]<vyrn-vnzsr>that's a good first start ;)
[23:26]<vyrn-vnzsr>lol
[23:26]<s19g>oddly, it wasn't letting http across either
[23:28]<vyrn-vnzsr>yea that is odd, but I've seen weirder with POSTROUTING rules
[23:30]<s19g>or... maybe it isn't allowing dns
[23:31]<s19g>it still doesn't seem to like dns
[23:31]<s19g>I can ping ips but not names
[23:32]<vyrn-vnzsr>s34n: you're not letting your nat machine provide dns to client boxen?
[23:32]<s19g>vice-versa: no
[23:33]<s19g>We have a cisco router that is buckling under nat load. My boss wants to through a dedicated nat server at the problem
[23:33]<vyrn-vnzsr>you have wget on one of the clients?
[23:33]<s19g>with the nat box doing nothing but nat
[23:34]<s19g>right now I have only one client - a windows laptop for testing
[23:34]<s19g>but I could put a client with wget on
[23:34]<s19g>why?
[23:35]<vyrn-vnzsr>I suppose, to me if it's gonna do NAT, might as well do DNS too and have some possible extra functionality
[23:36]<vyrn-vnzsr>you could use wget --server-response --spider http://www.google.com too help diagnose is what I'm thinking
[23:38]<s19g>vice-versa: frankly, I thinking nat-only is a perfectly splendid waste of a dual-Xeon server. But I'm not the boss.
[23:38]<s19g>I'm starved for app servers right now, too.

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