dr1

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • in reply to: vpn flooding logs #51192

    dr1
    Member

    For simplicty you can specifiy those options in the Extra options because it will accept them twice. I believe it wont accept keepalive if the ping options are set, but you can set the ping options twice, and keepalive is just a simplified way to set the ping options.
    Other option also is to set the value on the other side of the vpn to be compatible with the 7 second reset.

    I see this more of a feature request to have ALL the options be adjustable from the GUI, and I’d agree!

    in reply to: LAN to LAN – using dynamic addresses #51149

    dr1
    Member

    the option –float I belive is specified by default, if not that what you want

    in reply to: my zeroshell compromised [hacked] #51063

    dr1
    Member

    Ok for starters the bottom entry is a connection to LDAP, which is normal. So target phasers elsewhere, lol.
    Sounds to me, if anything happened, your asterisk machine was hacked.

    in reply to: DynDNS updates too often #50980

    dr1
    Member

    are you using net balancer? It runs a check to see if your IP has changed before it does an update, and actually I believe I manually changed that interval to make it higher. But it wont do an update unless it sees your IP has changed, and if you use net balancer you will need to make sure it can only access the 3 ips for the ‘checkip.dyndns.org’ site for the IP you want it to use. In the balancing rules you can set those 3 ips to only leave a certain interface. If ones down it will go out the other but unless your interface gos down every minute there shouldnt be a problem anymore.

    I made big assumptions here that you might be using net balancer since I had this same blacklist problem, if your not I apologize for wasting your time. 🙂

    in reply to: weird net balancer problems? #51014

    dr1
    Member

    Excellent that has seemed to fix it! Thank you Atheling for making this patch 🙂

    Only thing I had to do was manually add the 2 entries into the newly created NB_CT_PRE table, something with the ‘get interface from ip’ part of the script maybe didnt work, I will look into that. Net balancer wont let me set an interface (because its a vlan interface?) so I assume thats where it went wrong. Put in those 2 entries by hand and it seems smooth sailing now!

    I did this remotely last night and the machine mysteriously did not come back online for about an hour, lol.

    in reply to: weird net balancer problems? #51013

    dr1
    Member

    Ah ok, that is good to hear, I will have to try that patch out. I figured it was included at this point. I’ve never manually setup load balancing before so looking at it from the shell is still confusing to me. And yes definately about the problem with some websites. I was fully prepared to live with that, as I’ve done websites before that checked against IP, fortunately most sites now dont go that route. I had added a number of specific balancing rules to get around that.

    I will install patch as soon as I get back, thanks for info!

    in reply to: weird net balancer problems? #51011

    dr1
    Member

    http://www.zeroshell.net/eng/forum/viewtopic.php?t=1624&sid=1bb13d76980abd39ed7d447d7e5847c1

    seems to be a known bug. old post now, any new info? does seem it might not play nice with NAT. i thought a balancing rule of in eth00.2 out eth00.2 might do the trick but no help. is this a linux kernel bug i wonder?


    dr1
    Member

    i think raw in this case just means not using the normal tcp/ip stack? dhcpd on zeroshell is utilizing LPF(linux packet filter) to send the packets, which is still a udp packet but outside of iptables reach.. i guess. shrug.


    dr1
    Member

    I’ll also mention ebtables would not have helped the original poster I dont believe, since ebtables will only work on bridged interfaces. I’ve used it on dd-wrt myself though on the bridged interface with success.


    dr1
    Member

    I dont know. Looking at the source they seem to have included possibly 3 different methods of communicating. Its my understanding if they use normal udp alot of windows clients wont work.

    I did a bit more reading and it seems as though iptables is essentially getting a ‘clone’ packet, thats why the rules are triggering.

    Its extra odd that enabling the firewall rules trigged a “send_packet: Operation not permitted” error from dhcpd, though for only some of the packets it send, and yet the client did receive a fresh new ip anyways.

    Good information on the subject is not easy to find.


    dr1
    Member

    Chain INPUT (policy ACCEPT 5618 packets, 460K bytes)
    pkts bytes target prot opt in out source destination
    8 2640 DROP udp — any any anywhere anywhere udp dpts:bootps:bootpc

    Chain OUTPUT (policy ACCEPT 9077 packets, 2639K bytes)
    pkts bytes target prot opt in out source destination
    3 984 DROP udp — any any anywhere anywhere udp dpts:bootps:bootpc

    IP Address MAC Address Client Hostname State Start Time End Time
    10.3.250.20 00:24:b2:48:a6:ee SONYUX active 2010/08/25 11:53:51 2010/08/25 19:53:51

    root@gateway root> date
    Wed Aug 25 11:56:39 EDT 2010

    im always trying to make sure im not putting my own foot in my own mouth either, so there you go 🙂
    There used to be an option in 2.4 called ‘CONFIG_FILTER’, that may be enabled in 2.6 by default because its no longer an option, however it doesnt seem to apply to iptables. As the option itself in the description says its ‘ok to leave disabled’ since unless your a programmer you wont be utilizing it anyways, lol.


    dr1
    Member

    All I can tell you is I suggest you go ahead and perform a little experiment and see for yourself, or you will just be added to the giant list of people who put their foot in their mouth, lol. A google search will show you this.

    http://lists.netfilter.org/pipermail/netfilter/2002-May/034387.html

    http://ubuntuforums.org/showthread.php?t=1210187

    in reply to: Openvpn – blocking dhcp remote dhcp requests with ebtables #47137

    dr1
    Member

    I have no problem with the rule, the rule catches it fine. iptables is just incapable of blocking the traffic dhcpd is sending and receiving.

    You have todo a little searching because people tend to give advice about stuff they havent actually played with before, but, lol. Its my understanding iptables cannot effect the raw sockets dhcpd is using for communcation.

    I had an old firewall rule in place from a prior experiment set to block all dhcp traffic, didnt realize it and the counters were up to like 300.. of course it never stopped a shred of dhcp traffic the rest of my network worked fine, lol. After I did a little research i figured I would chime in, and also to find out if whatever supposed module iptables is using to replace ebtables functionality, if it would actually work in this case.


    dr1
    Member

    I was running into a similar situation, and if you hand load the ebtables module you can use it from the command line (at least now, i realize this is an old post)

    I got a question about the interface though. The ‘Apply To: Routed or bridged interfaces’ only comes up for the FORWARD chain. Can this be applied to the INPUT and OUTPUT chains as well? And if it was, would it use some ebtables module to be able to block things like DHCP with the interface?

    because while you can add a rule with iptables to the input chain, to block DHCP, and it will get triggered. it wont work, because dhcpd and iptables are basically operating at the same layer.

    in reply to: ip_conntrack_tcp_timeout_established #50971

    dr1
    Member

    Just some info, I discovered how I ended up with all those entries: http://forums.gentoo.org/viewtopic-t-463726.html

    I’ve actually managed to more or less force expire the conntrack count down to 10000 now (down from ~55000) and it freed about 65M of ram in the process.

    I have this in my boot script now.

    echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
    echo 16000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max (I know this is low but its restricted to 4096 by forces out of my control anyways)
    echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose

Viewing 15 posts - 1 through 15 (of 15 total)