How can I send connections to a specific hostname into the cold empty void?

Discussion in 'Tomato Firmware' started by lanmtl, Sep 27, 2010.

  1. lanmtl

    lanmtl Addicted to LI Member


    I'd like my router to discard/block/not even process connections to on TCP port 443.
    This is Snow Leopard's Core Location daemon but it's so buggy that it creates hundreds of connections in a few seconds and keeps them alive all the time by exchanging an unreasonable amount of traffic.
    This confuses the hell out of the WRT54G, so much so that I get terrible pings (pingtest to is normally about 30ms and 4ms jitter, but when Core Location comes in I get about 10% packet loss 500+ms ping and 300+ms jitter)
    I have a feeling it's got to do with dnsmasq but I'm not so sure…
    I could disable Core Location in OS X altogether, but this would be a quickfix and would leave the router exposed when other Macs with Core Location enabled connect to our network.

    Thanks for your help!
  2. rhester72

    rhester72 Network Guru Member


    iptables -t filter -A wanout -p tcp -d --dport 443 -j REJECT

  3. lanmtl

    lanmtl Addicted to LI Member

    Thanks a lot :)
  4. Azuse

    Azuse LI Guru Member

    If traffic is lagging you need to sort your qos and limit the number of connections, not simply block it because the qos isn't correctly setup :-/
  5. RonWessels

    RonWessels Network Guru Member

    Just one comment regarding this command. It uses the current IP address of until the router firewall gets restarted (either by router reboot or some other configuration change). So if the IP address for changes with the appropriate change to the DNS entries, you will still be blocking the old IP address.

    Having said that, I doubt this is an IP address that changes much.
  6. mstombs

    mstombs Network Guru Member

    Likely the dns name lookup would fail in the firewall script which runs before the wan is up. I suggest to use the IP directly.
  7. rhester72

    rhester72 Network Guru Member

    The IP address isn't used in case it does change or has multiple hits - AFAIK, iptables will re-evaluate as necessary when the TTL expires out of cache just like any other lookup, so it's a safer approach.

    This having been said, mstombs is also correct - the firewall script does fire first, so you're kinda forced into hard-coding an IP instead. :/

  8. teddy_bear

    teddy_bear Network Guru Member

    Really? I thought that even if for some connection types the firewall is started (and script runs) early, it is getting restarted again once the WAN is up. At least in the code it looks that way...
  9. mstombs

    mstombs Network Guru Member


    If anyone knows I am sure you do - I remember looking at the stock tomato code a long time ago and putting logger messages in the scripts to be sure of the sequence and timing - only on dhcp WAN mind. (and my WAN-UP only sends one email...)


    Again I am surprised I disagree - I've always understood the userspace app iptables converts hostnames to IP addresses once only when inserting the rules into the kernel filter tables. Such lookups don't require dnsmasq, I assume they use libresolv, and will use the hosts file if available.
  10. pfoomer

    pfoomer LI Guru Member

    Just tried this, entered rule, saved, no effect.
    Rebooted router tried again, blocked.
  11. rhester72

    rhester72 Network Guru Member

    I thought about this again after TB's reply, and he's right - the firewall script is triggered after every WAN Up (but before the WAN Up script itself). This kind of makes sense, given that most firewall rules require you to know your WAN IP to function. =)

    It makes sense that it would be the case, and I made the same initial assumption - but if you take a look at the memory space after loading the rule, it is clear that iptables is actually inserting the name, not the IP. From strace:

    send(3, "\0\2\1\0\0\1\0\0\0\0\0\0\fmac-services\5apple\3"..., 40, 0) = 40
    recv(3, "\0\2\201\200\0\1\0\1\0\0\0\0\fmac-services\5apple\3"..., 512, MSG_DONTWAIT) = 56
    The IP never appears.

    However...a live debugging session with dnsmasq did *NOT* show any attempts from the kernel stack trying to resolve the name (which would be hellishly expensive every single time the netfilter chain is traversed...on every packet!). I also used wget (the real thing, not busybox) to verify that if I "block" by name on port 443, it still allows traffic through, which confirms that only IP is allowed (it is in fact storing the name in the netfilter chain, and then utterly ignoring it because it's not a valid IP).

    Long story short: Don't use the name in the rule. The current IP is and is the only one, so it should be fine to use unless/until it changes.

    Sorry for not digging further on this one - I (stupidly) assumed iptables would reject the rule if the destination was invalid.

  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Maybe it's a difference between Linux 2.4 and 2.6, but I'm seeing it work as evaluated once as it's inserted into the iptables chain (or possibly stored as the name and evaluated as part of the listing, but I doubt it - regardless, inserting it as a name does work):
    # iptables -t filter -nvL
    Chain OUTPUT (policy ACCEPT 875K packets, 208M bytes)
     pkts bytes target     prot opt in     out     source               destination
    # ping -c 1
    PING ( 56 data bytes
    [color=green]64 bytes from seq=0 ttl=57 time=31.536 ms[/color]
    --- ping statistics ---
    1 packets transmitted, 1 packets received, 0% packet loss
    round-trip min/avg/max = 31.536/31.536/31.536 ms
    # [color=blue]iptables -t filter -A OUTPUT -d -j REJECT[/color]
    # iptables -t filter -nvL
    Chain OUTPUT (policy ACCEPT 875K packets, 208M bytes)
     pkts bytes target     prot opt in     out     source               destination
    [color=red]    0     0 REJECT     0    --  *      *         reject-with icmp-port-unreachable
        0     0 REJECT     0    --  *      *         reject-with icmp-port-unreachable
        0     0 REJECT     0    --  *      *         reject-with icmp-port-unreachable
        0     0 REJECT     0    --  *      *         reject-with icmp-port-unreachable
        0     0 REJECT     0    --  *      *         reject-with icmp-port-unreachable[/color]
    # ping -c 1
    PING ( 56 data bytes
    [color=red]ping: sendto: Operation not permitted[/color]
  13. TexasFlood

    TexasFlood Network Guru Member

    What about setting up an access restriction rule to block http references to "" on port 443?
  14. RonWessels

    RonWessels Network Guru Member

    The way that it works for iptables, for routing tables, for connection tables, and for anything else in the kernel that deals with IP addresses is: the user-level interface program will typically accept host/network names which it then does a DNS/hosts lookup to turn into an IP address. It will also accept IP addresses directly (it actually comes for free in the DNS lookup, since a lookup of "" returns That IP address is used within the kernel. The kernel never never never performs a DNS lookup to do anything. When tables are displayed, the user-level interface program will perform a reverse-DNS lookup on the retrieved IP addresses to turn them back into names. Most of the programs will also have a option to disable the reverse-DNS lookup and simply display the IP address numerically.
  15. rhester72

    rhester72 Network Guru Member

    So then the bottom line is the name _should_ work, even if DNS has multiple entries for it (the above shows one entry per address), so long as the WAN is up when the rule is fired (and since the firewall chains are rebuilt each time the WAN link comes up, it *should* be). Am I understanding correctly?

  16. jbaker6953

    jbaker6953 LI Guru Member

    A persistent route would work too. You could be real devious and cause dnsmasq to issue the bogus route as a part of the DHCP assignment by putting something like this in your dnsmasq custom configuration box:

    This indeed does cause my Windows 7 machine to place the following in my routing table:

    IPv4 Route Table
    Active Routes:
    Network Destination        Netmask    Gateway       Interface         Metric
           20       21
    That, in turn, causes this joy:

    Tracing route to []
    over a maximum of 30 hops:
      1  desktop []  reports: Destination host unreachable.
    Trace complete.
    I like this solution because you're making their machine do the filtering work instead of the router. Ideally you could issue a null route for that IP via DHCP but I haven't figured out how to do that in a reliable, cross-platform way.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice