Captive portal not properly catching traffic

Home Page Forums Network Management RADIUS 802.1x and Captive Portal Captive portal not properly catching traffic

This topic contains 3 replies, has 0 voices, and was last updated by  tnyoung 4 years, 4 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #43990

    tnyoung
    Member

    I’ve been trying out zeroshell as a gateway aboard a ship to manage multiple wan connections and provide user bandwidth accounting. For some time now we have been experiencing satellite bandwidth usage that isn’t reflected in the zeroshell accounting.

    Brief description of network.
    Latest zeroshell running on a soekris net6501-50
    ETH00: Roadrunner shore cable (only connected in port)
    ETH01: 4g cellular modem (not completely implemented yet)
    ETH02: Sailor fleet broadband 500 (static ip)
    ETH03: LAN 192.168.1.1, DHCP server.

    Forward chain of the firewall

    Chain FORWARD (policy DROP 480 packets, 31522 bytes)
    pkts bytes target prot opt in out source destination
    14991 18M ACCEPT all — ETH00 * 0.0.0.0/0 192.168.1.0/24 state RELATED,ESTABLISHED
    601 49166 ACCEPT tcp — ETH02 ETH03 0.0.0.0/0 192.168.1.0/24 state RELATED,ESTABLISHED
    0 0 ACCEPT icmp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED icmptype 8
    1209 149K ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:80
    10731 1503K ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:443
    0 0 ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:51490
    0 0 ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:110
    0 0 ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:587
    0 0 ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:465
    0 0 ACCEPT tcp — ETH03 * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:993
    7 324 ACCEPT tcp — ETH03 * 192.168.1.99 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpts:6500:6600

    As an experiment, I tried sending an email of a known size and receiving it using the ship’s onboard email server over the satellite connection.

    https://www.dropbox.com/s/bw3eh7khijk36dz/1.png

    Starting with a fresh captive portal login on the email server (0.00MB), I told the ship’s email server to retrieve mail from the shore server. The above is a picture of it pulling in a 1.5MB email which I previously sent it for this purpose. The bandwidth usage on the satellite interface (right side of screen) shows 81087.27MB of data.

    The next picture shows the bandwidth usage after the email has been retrieved and the captive portal authenticator has been refreshed.

    https://www.dropbox.com/s/v5s9qmzoxt5xalo/2.png

    The satellite interface shows 81088.97, for a difference of 1.7MB (email plus overhead) while the captive portal only shows a difference of 0.3MB.

    I let the connection run for a few more minutes and additional traffic went through, but here is the entry for that connection from the accounting page.

    192.168.1.99 / e8:40:f2:e1:0e:f3 zeroshell 14-07-22 08:00:04 14-07-22 08:15:23 0.43 0.25 0.68 0:15:19 0.629 14-07-22 08:15

    Any ideas why the captive portal isn’t accounting for all the traffic? Http works fine.

    #53383

    redfive
    Participant

    By enabling the Captive portal, some (hidden by gui) rules are add in the FW chains, in the FORWRAD chain is at the end, (click on view button).
    If all your clients are behind the captive portal, and you’d to allow only some specific services , I’d proceed as follow..
    firstly , create a new chain, eg. Allowed_Serv , then add one rule for each service that I want allow, eg.


    1 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:80
    2 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:443
    3 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:51490
    4 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:110
    5 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:587
    6 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:465
    6 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:993
    7 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpts:6500:6600
    8 * * RETURN tcp opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0 icmptype 8
    9 * * DROP all opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0

    Then , in FORWARD chain, only(*) two rules, the first one, with action jump to chain Allowed_Serv, while the second one, will deny connections initiated from any ip which isn’t 192.168.1.99 and destinated to tcp port range 6500:6600


    1 * * Allowed_Serv all -- ETH03 * 192.168.1.0/24 0.0.0.0/0
    2 DROP tcp -- ETH03 * !192.168.1.99 0.0.0.0/0 tcp dpts:6500:6600

    Very basic , but above all … not tested , you can try “at your own risk” 😆
    (*)To be honest , you can do much more here, and also in input chain, but I don’t know what are , eg. your goals, or if you have some services which must be reacheable, and so on….

    Regards

    #53384

    tnyoung
    Member

    Thanks for the reply. I’ll take a closer look at the firewall. Is there a reason why putting the rules in a separate chain vs in the normal fwd chain would affect the radius accounting? If anything, I would think it might be the input chain that could affect the radius accounting.

    #53385

    redfive
    Participant

    AFAIK , for the accounting in conjunction with the captive portal, the packets must be processed by the “captive portal chain”, if there are some rules that allow the forwarding of the packets out from an interface before they reach the “captive portal chain” , the accounting doesn’t work properly. So , the custom rule , if there is a match , allows packets to proceed in the FORWARD chain until they reach the “cp chain” , if there is no match, packets are dropped at the end of the custom chain.

    Regards

    #53386

    tnyoung
    Member

    I see. Running an iptables -L in the console, I can see the rules in the CapPortFS chain. I was seeing a lot of dns lookups over port 53 in the connection tracker and there is a rule here that lets them through. This is where the free authorized services on the captive portal page come into play.

    Couldn’t I require that udp/53 traffic to also authenticate through the captive portal? I am not particularly worried about people setting up a udp tunnel to get around the captive portal, but I would like to account for every packet that goes out over satellite. Satellite data costs about $1/MB for us, and with udp packets streaming out, it quickly adds up.

    Another question. By putting a couple rules in the fwd chain to allow traffic out over a particular interface (and in) before it hits the CapPort chain, could I bypass the captive portal (not have to manually turn it off) when the ship connects to shore via a cable connected to eth0?

    Thanks

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

You must be logged in to reply to this topic.