IRC Logs

Network: freenode Channel: #iptables

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

[13:36]<d9e>+ignoring (:
[13:52]<-- svgvsdyzgjvr xrs>/dev/null")
[14:45]<drvvx_>-< sid> Is it possible to admin a box remotely that has no ports fowarded? I want the box to connect to me...and wait for my commands. <-- rrs (reverse remote shell)
[14:46]<drvvx_>-too bad he left
[14:52]<zj20>+What would you have suggested? I have one like he described, no direct access, but it makes an openvpn connection and I ssh through that.
[14:54]<zj20>+I even used openvpn to ssh through an evil "2wire Homeportal" router a/k/a mangler. Stupid PoS kills every TCP connection every 60 seconds! But openvpn (udp) worked smoothly.
[14:56]<drvvx_>-openvpn is overkill for a simple remote access, rrs does the deed
[14:57]<drvvx_>-http://www.cycom.se/dl/rrs
[14:58]<zj20>+
ACTION shrugs ... seemed simple enough.

[14:59]<zj20>+The isolated remote box also runs Samba through the VPN.
[15:02]<zj20>+Does the rrs shell exit if the client disconnects?
[15:10]<svnvnn61>+rob0, are you here?>
[15:10]<svnvnn61>+i saw your suggestion. the nics seem to be fine, but there doesn't seem to be routing between them
[15:11]<svnvnn61>+for instance, i can get to the iptables box without a problem, and from the iptables box, i can get to the internet fine, as well
[15:14]<drvvx_>-rob0: the session ends, next time the client will get polled you'll be able to re-open a shell session
[15:15]<drvvx_>-if you screen the client's session you got a permanent shell
[15:15]<asvjzd>+Hello all. The question of the day - how to route DHCP?
[15:16]<drvvx_>-using stuff like bcrelay ?
[15:16]<asvjzd>+The idea is to route to the server in Xen virtual machine.
[15:17]<asvjzd>+I'll check out this bcrelay, maybe it'll be what I want.
[15:17]<drvvx_>-Description: Broadcast relay daemon
[15:17]<drvvx_>- The bcrelay daemon relays broadcasts between two interfaces. It is shipped
[15:17]<drvvx_>- with the pptpd package, but can be used for other purposes.
[15:18]<asvjzd>+Still, a daemon in the dom0.
[15:18]<asvjzd>+So it is an attack point. If I wanted a daemon in the vm controller, I'd place the well-tested dhcpd there.
[15:23]<drvvx_>-ethernet bridging could be a solution too
[15:24]<asvjzd>+I'd have to convert my iptables rules to work with it... It is an option though.
[15:24]<drvvx_>-doing it's own bridging in userland with ipqueue, another (fun) one
[15:25]<drvvx_>-s/it's/its/
[15:25]<asvjzd>+matth_: 3 interfaces -> 1? it isn't possible with ipqueue I think. At least not easily.
[15:28]<drvvx_>-"easy" is quite subjective ;)
[15:29]<drvvx_>-ipqueue can help you doing broadcast relay between interfaces with cool scripting languages
[15:29]<asvjzd>+Let's see... I'd have to write in C.
[15:29]<asvjzd>+Anything compilable, at least.
[15:31]<drvvx_>-just evaluate the possibility I gave depending on your needs/skillz, and do what you prefer
[15:31]<asvjzd>+I'll try that bridging firewall. Hope it'll work out well.
[15:34]<zj20>+matth_: rrs+screen is a cool idea, thanks for the tip.
[15:34]<drvvx_>-yw
[15:36]<zj20>+AStorm: there's also a proxy, I think it's called dhrelay or something like that.
[15:36]<zj20>+I've never used it
[15:37]<asvjzd>+I don't trust any servers enough to place them in dom0.
[15:37]<asvjzd>+
ACTION is now fighting with bridges

[15:37]<drvvx_>-(oh yep, dhcrelay instead)
[17:43]<zuynm>-hello, I think that my provider is slowing my connection down if my computers are behind a router. when for example I access www.google.com with my router, it is extremely fast, but if I do a www.google.com with one of mine intranet pc's, I notice a lag of 3 or 4 seconds
[17:44]<zuynm>-could it be the dns slowing me down the reponses based on the ttl?
[17:45]<asvjzd>+ruied: it's possible to set up something like that.
[17:45]<asvjzd>+Anyway, you can change the TLS of the packets on their way.
[17:46]<zuynm>-tls? (I whas trying widh ttl...), what is tls?
[17:47]<asvjzd>+ttl, sorry, brainbug :P
[17:47]<asvjzd>+Too much thread programming lately :P
[17:49]<zuynm>-AStorm: I was trying to change the ttl value at the mangle table... but I didn't notice any difference... what is the default ttl value? where shall I put it, at the $WAN interface? I'll pass to here just my ttl line...
[17:49]<asvjzd>+You can measure the default TTL with LOG target :-)
[17:51]<zuynm>-ah, ok.. :) going to try it
[17:57]<zuynm>-do I need to load any module to have the mangle table ? (it's reporting the error: No chain/target/match by that name)
[17:57]<asvjzd>+You have to.
[17:58]<zj20>+iptable_mangle, for one
[17:58]<asvjzd>+(or alternatively compile it into the kernel)
[17:58]<zuynm>-ok! :) thank... for now going to try as a module...
[18:05]<zuynm>-I've loaded the module (it appears at the insmod output) and tryed: "iptables -t mangle -A PREROUTING -i $WAN -j TTL --ttl-set 64" but it reports the same error "No chain/target..."
[18:06]<asvjzd>+You haven't loaded the TTL target.
[18:07]<zuynm>-hmm... don't understand... I normally use iptables, but never worked with mangle and ttl... I'm missing something here...
[18:08]<asvjzd>+Yes, iptables ttl target.
[18:08]<asvjzd>+:-)
[18:09]<asvjzd>+modprobe iptables_ttl maybe?
[18:09]<asvjzd>+or iptables_mangle_ttl
[18:09]<asvjzd>+I'd have to check.
[18:10]<zuynm>-:) ok, going to take a look
[18:11]<zj20>+ipt_ttl in my 2.6.15
[18:11]<zj20>+no, that's ipt_TTL
[18:12]<zuynm>-worked with ipt_ttl
[18:12]<drvvx_>-ipt_ttl is the matcher module only
[18:13]<asvjzd>+ipt_mangle_ttl maybe? Heck, use the module autoloading :-)
[18:13]<zuynm>-ipt_TTL dowesn't exist (kernel 2.6.18-bf2.4 debian)
[18:13]<zuynm>-ok
[18:13]<drvvx_>-you probably need to get it from pom
[18:14]<asvjzd>+2.6.18? wtf?
[18:15]<zuynm>-wtf?
[18:16]<drvvx_>-(he meant 2.4.18 of course)
[18:16]<-- dvxn|syzzzyus xzs>http://www.bagdadsoftware.de")
[18:17]<asvjzd>+There's no ipt_TTL in 2.4.18 I think. He'll have to use PoM
[18:18]<zuynm>-ah, it's 2.4.18, not 2.6. ... :)
[18:19]<zuynm>-is it better to change to 2.6 ?
[18:20]<asvjzd>+I guess, unless your hardware is incompatible. But you never know... :-)
[18:20]<zj20>+2.6.16?
[18:20]<zj20>+2.6.16 is the development branch :)
[18:20]<zj20>+2.6.16?
[18:20]<drwygn>+2.6.16 is, like, the development branch :)
[18:20]<asvjzd>+maxine: nope
[18:20]<drwygn>+AStorm: sorry...
[18:21]<zj20>+
ACTION loves teasing maxine

[18:21]<asvjzd>+2.6.16.16 is stable, currently :-)
[18:21]<asvjzd>+The rule is simple - wait 2 weeks before updating (or not) to the next 2.6.x
[18:22]<asvjzd>+patch releases don't count.
[18:22]<zuynm>-I think it wouldn't be a problem... (well, my processor is a litle bit strange... cyrix mediaGX 180MHZ) :)
[18:22]<zj20>+Ah, I missed that part of it. :)
[18:22]<zj20>+2.6.16.16?
[18:22]<drwygn>+2.6.16.16 is stable, currently :-)

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