@# Quotes DB     useful, funny, interesting





Google
 
Web www.quotesdb.info
Undernet  |  EFnet  |  Quakenet  |  Freenode  |  Dalnet  |  Ircnet  |  Galaxynet
Page: 1 2 3 4



Comments:

<0> re
<1> hi
<2> I keep getting packets on udp ports 137:138. Many times originating from no where near me. Sometimes originating from my routers.
<2> These ports are used for NETBIOS Name Service and NETBIOS DAtagram Service
<2> But I have no idea if I should drop these or not.
<2> Is this something I should drop?
<3> drop them unless you're running samba and need them
<2> Why the heck would my routers (colocation facility's routers) be sending these packets? Should I notify them that they may have a problem?
<3> are the router doing NAT? maybe it's a machine behind them?
<2> I am using DNAT/SNAT. Would that maybe cause the routers to send these messages?
<3> no, but it would cause computers behind the router that are sending the messages to look like the router is sending them
<3> the router is probably not the one sending the messages
<2> BTW The routers aren't using NAT because I have a public IP address.
<2> OK.
<4> hi all
<5> hi



<4> how do i make rule numbers?
<3> iptables -vL --line-numbers ?
<4> iptables -I [NUBER?] bla bla bla
<4> ?
<3> oh, iptables -I INPUT 2 blah blah
<4> ic .. thxz
<4> danieldg: i more Q.. will iptable excec the rules in order?
<3> yes
<4> ok.. nice :)
<4> hmm how many rules number can one have?
<4> and insert
<4> i get this message index of insertion too big
<3> octan: you need to insert rule 1 first, and so on...
<6> could someone help me diagnose a IPTables problem?
<6> DNS isn't working on the local machine, but machines in the NAT are working just fine
<3> try adding LOG rules, or I can look at the ruleset (iptables-save output)
<6> do you want that pasted in #flood?
<3> pastebin
<6> http://pastebin.com/579594
<3> what are eth0 and eth1?
<6> eth0 is Internet Interface, Eth1 is internal (NAT) interface
<3> you're not allowing any locally generated traffic out eth0
<6> something like a "-A OUTPUT -o eth0 -j ACCEPT
<6> " would fix that?
<3> yes. I would just change the policy on OUTPUT to ACCEPT
<3> since you're not filtering it anyway
<6> well I'm further after adding that rule
<6> now a ping www.google.com just stalls
<3> does it resolve google.com to an IP?
<6> Previously i was getting an unknown host... So I am not sure.
<6> It may be, is there anyway to just test that?
<3> I'd just use 'host google.com'
<6> nope, stalls
<3> what DNS server are you using? your ISP's?
<6> yep and they're working cuz I am using them from behind the router
<3> you could try seeing what packets are being sent/recieved
<6> how would I go about that?
<6> http://pastebin.com/579614 I repasted the current output now
<3> packet sniffer like ethereal
<3> wait... you don't have an iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT rule
<3> you deleted it
<6> That fixed it!
<6> its working
<6> thanks a ton
<3> yw
<2> I SNAT an outbound udp packet (53 - DNS lookup). I confirmed the rule executes by logging before/after.
<2> I try to catch the response in the PREROUTING chain but never get one.
<2> My understanding is that the next step is to go out eth0. How can I prove it went to the DNS server?
<2> Or, how can I prove that the packet is coming back but I'm just not handling it correctly?
<7> try to catch (LOG) it in the filter table?
<8> yeah, log in and out on the outside interface
<2> Wouldn't the packet hit prerouting first?
<8> no, filter first, then nat, IIRC
<7> IIUC not if it's a known (conntrack) connection.
<9> yeah, iirc, nat table on gets first packet of a new connection
<7> No, normally nat is first but only --state NEW.
<9> er, prerouting chain, that is
<7> like robw810 said :)
<7> This is why they (they = writers of documentation and netfilter devel's) say not to try to filter in the nat table.
<9> yep
<8> tell ya what, ill do a little experiment, and ULOG in and out, pre, forward and post, and see what order they come in



<2> So once I SNAT in postrouting, the response will come back through FORWARD first? (I have two bridges. DNS lookup comes through br-apps -> br-dmz)
<9> rob0: you should be working on that server :-)
<7> Too tired now :)
<9> hehe
<7> It sure does look nice tho.
<2> I guess that is why they call it "filter" :-)
<2> Nielsen: Whatever you find, let me know.
<2> I have been banging my head flat on this.
<7> nat PREROUTING comes before filter; nat POSTROUTING, after.
<2> Even on a SNAT'd response?
<7> s/POSTROUTING/POSTROUTING and OUTPUT/
<9> There's a nice png somewhere of packet flow; I wish I had it bookmarked
<2> Me too. :-)
<7> google can find it
<7> I don't think that diagram covers the new raw table.
<7> IIRC it was by some guy in Alaska.
<2> I have a great one but it doesn't give details on the difference between normal and SNAT'd/conntrack
<8> onweald_tim: doesnt even hit INPUT or OUTPUT - www.docnielsen.dk/TEST.txt
<2> *looking*
<2> Nielsen: Was that SNAT'd to your public IP address?
<2> Nielsen: If 192.168.1.123 is not on your machine (e.g. you are bridging) then it would make sense it wouldn't hit INPUT or OUTPUT.
<8> im only natting...
<8> 192.168.1.123 is me, 212.242 is the dns server
<2> When you say natting, you are using the DNAT target?
<2> I give up. Heading to sleep. Ciao gang.
<10> why the rules: iptables -P INPUT DROP; iptables -A INPUT -p tcp --syn -m limit --limit 10/s -j ACCEPT block my ssh conections? SYN packets are only used in the three-way-handsake protocol, right?
<2> sgrq: My understanding is that syn packets are used for tcp handshakes
<10> onweald_tim: yes
<10> well I miss the rule iptables -A INPUT -p tcp --dport 22 -j ACCEPT
<10> but in any case it still doesn't work
<2> Do you have a state check for established and related?
<10> my goal is to limit the syn packet's traffic
<10> onweald_tim: no, I don't use the stat match
<10> *state
<2> I have been using that at the start of INPUT to skip the other filters. But I guess it isn't required.
<10> onweald_tim: it still doesn't work with the ESTABLISHED,RELATED state -j ACCEPT at the top of the rules
<10> mmm it works but I need to wait some seconds to get the P***wd: of ssh
<11> Hello , i need some help with iptables ..anyone around?
<12> you can start by asking a question
<12> and stop wasting time with meta questions
<11> ive got a linuxbox acting as a firewall and windows clients , they use outlook express how do i let them send and recieve mail.
<11> what rules am i supposed to use?
<11> i need to forward p 110 and 25
<12> no you dont
<12> or yes
<12> depends on your current rules
<12> iptables -L && iptables -L -t nat
<12> pastebin.com that
<11> rza , currently im using squid on the linuxbox and i have setup rules only for it
<12> so no nat at all?
<11> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
<11> ^^
<12> thats the only rule?
<11> well yes ,atm
<12> eth0 is the lan interface?
<11> im yeah
<11> yes*
<12> ok, second
<12> are the policies set to drop?
<11> rza no.
<12> echo 1 > /proc/sys/net/ipv4/ip_forward
<12> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
<12> theres basically the simplest nat rules for you
<11> mm
<11> rza, on the MUA , i have to specify a proxy right?
<11> i mean in outlook express i have to specify a proxy right?
<12> no
<12> why would you if you make a nat?
<12> if you want to use proxy why dont you just make rules like iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 110 -j REDIRECT --to-port 8080
<11> cuz i was tailing tcp requests on the linux box and after setting the mua to use the proxy it dosent request the proxy for *online.mailserver
<11> it just looks directly for *online.mailserver on the local lan
<11> correct me if i said something weird
<12> im just wondering do you want full nat?
<12> or to use proxy with your clients


Name:

Comments:

Please enter the result of the sum 63 + 46 (to avoid spam):






Return to #iptables
or
Go to some related logs:

WPA_Supplicant backtrack install
#bash
py2cpp
#gentoo
#suse
smart repository ksteak
gnome useflags make.config gentoo
latitude C610 run XGL
force an application to use a proxy
#oe



Home  |  disclaimer  |  contact  |  submit quotes