Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 2 subscribers
  • Views 16203 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange time-block issue

marton
Hello
I have a home use version of Astaro. Firewall works fine (at the most)..
Problem now is that it seems to be blocking access in the morning until 08:00 CET (NOTE this is Central European Time). I have not configured any Time Event and I find it strange that the firewall blocks.
1 minue past 08 and everything works.

NOTE! This is accessing from the outside in. I have never experienced this problem on the inside.

Any Ideas what may be the problem?
I have tried now creating a All_time time-event (00-23:59 all days) and configure all my packet filter rules against this, just to test.

/MartOn


This thread was automatically locked due to age.
Parents
  • 0
    With all the problems of Astaro, packet filter is the most stable thing about it.
    You do not have to define time events at all (Definitions --> Time Events) for the packet filter to work. And therefore in your packet filter rules, you don't have to tinker with the time events column at all. Don't get confused with time events and create a simple rule first till you get comfortable with basic operation of the firewall.

    A little more information about your rule that is giving you problems would help in troubleshooting it. 

    As far as pfsense is concerned, it looked like it was based on m0n0wall. Which I am sure is great but does not have half of the advanced functions of astaro including IPS and various proxies (smtp being the most important for me).[:)]
  • 0 in reply to Billybob
    I know about the packet filter and time events. I did not configure any time events. I just tried it after this problem occured.

    I am wondering now that it may be a license issue. I often get mails that I exceed my license of max 10 connections..

    This max 10 connection is lame and out dated (who hasn't 10 ip connections today, even printers are counted). Astaro pricing is so non-"home user friendly" that they could for sure expand it without loosing any money. Or they could create a cheap home user version. I think that increasing the the home-usage lisence would increase number of users and also increase business because more people would talk about it.

    I love astaro, I even tried to buy it for home use. But around €700 for the license and €460 for maintenance, they can forget it.

    /MartOn
  • 0 in reply to marton
    Marton,
    from understanding it is only outgoing users that are counted. If a printer is being used by a VPN it would not be seen by the firewall because it is within an encrypted pipe.

    There is no difference in the application between a homeuser and business. The differentiation comes in the licence purchased.

    Ian M
  • 0 in reply to RFCat_vk_01
    Hello
    What you write is not true in most cases. You do not terminate your VPN in same ip-range as your LAN. I have assigned a separate IPSec-pool where all VPN connections are terminated. That netowork is routed by Astaro.

    But back to business (or non business).
    I have now concluded that it is not the license issue thats causing my problem. Still my firewall blocks until 08:00 in the morning. It is so strange when I have never configured any time-events, I do not use IDS features, ony Packet-filters and NAT-Masq.

    Is there someway I can attach my firewall config to this forum, without compromizing all my security and pre-shared keys?

    /MartOn
  • 0 in reply to marton
    Marton,
    it doesn't sound like an Astaro issue, it sounds more like your ISP has some form of block in place. Are you running with a home connection or a small business connection? Some ISPs get upset with customers running servers from home on a home user account.

    Can you see the failed traffic in the packet filter log?

    You might put some of the packet filter report in this thread.

    Ian M
  • 0 in reply to RFCat_vk_01
    Hello
    I do not get blocked (AFAIK). 
    I have 20Mbit fiberconnection with static IP and we are allowed to run servers for personal use.
    I found one strange issue:
    2006:09:19-07:46:23 (none) ulogd[1851]: DROP: IN=eth1 OUT= SRC=x.x.142.93 DST=x.x.140.3 LEN=40 TOS=00 PREC=0x00 TTL=252 ID=19250 PROTO=TCP SPT=56723 DPT=80 SEQ=0 ACK=0 WINDOW=0 RST URGP=0 
    2006:09:19-07:46:51 (none) ulogd[1851]: DROP: IN=eth1 OUT= SRC=x.x.142.93 DST=x.x.140.3 LEN=40 TOS=00 PREC=0x00 TTL=252 ID=549 PROTO=TCP SPT=56727 DPT=80 SEQ=0 ACK=0 WINDOW=0 RST URGP=0 
    2006:09:19-07:47:15 (none) ulogd[1851]: DROP: IN=eth1 OUT= SRC=x.x.142.93 DST=x.x.140.3 LEN=40 TOS=00 PREC=0x00 TTL=252 ID=10248 PROTO=TCP SPT=56728 DPT=80 SEQ=0 ACK=0 WINDOW=0 RST URGP=0 
    2006:09:19-07:47:27 (none) ulogd[1851]: DROP: IN=eth1 OUT= SRC=x.x.142.93 DST=x.x.140.3 LEN=40 TOS=00 PREC=0x00 TTL=252 ID=15063 PROTO=TCP SPT=56729 DPT=80 SEQ=0 ACK=0 WINDOW=0 RST URGP=0 
    2006:09:19-07:47:31 (none) ulogd[1851]: DROP: IN=eth1 OUT= SRC=x.x.142.93 DST=x.x.140.3 LEN=40 TOS=00 PREC=0x00 TTL=252 ID=30017 PROTO=TCP SPT=56730 DPT=80 SEQ=0 ACK=0 WINDOW=0 RST URGP=0 
    (x.x.140.3 is my static public IP'address)

    As you can see from this (removed MAC and some IP'info), traffic to port 80 is blocked. This is strange, because normally this traffic is masquraded to a internal LAN IP'adress and the masquraded package is sent through the packet filter.

    NOTE! The x.x in source and dest is actually the same because I'm testing from same ISP.

    My Masq rule is like this:
    Any -> External (Address) / HTTP  None  webserver_external
    where HTTP service is: HTTP  TCP  1024:65535  80  static 
    and webserver_external is my webservers public ethernet interface.

    Any Ideas?
    /MartOn
  • 0 in reply to marton
    Marton,
    What is your associated filter rule that lets the traffic into the LAN?

    Ian M
  • 0 in reply to RFCat_vk_01
    Web - Any 0.0.0.0/0 HTTP 192.168.3.20 webserver_external

    /MartOn
  • 0 in reply to marton
    Marton,
    I think I have it.

    You need to setup a service where you define the http say as
    httpmarton tcp 80 (source) 1024:65535 (destination) "external access to my server". 
    Check the filter rules in detail in the filter rules menu and see if any incoming rules are shown.

    If this doesn't work I am out of ideas.

    Ian M
  • 0 in reply to RFCat_vk_01
    The strange part here is that it normally works. It is just at certain times it does not.. And when that happens, nothing works, not even ping.

    /MartOn
  • 0 in reply to marton
    Marton,
    out of ideas how to fix it, lets try some investigation.

    Have a look at the filter rules :_
    webmin-> filter rules->Current system packfilter rules
    you should see a set of rules like this is if you have time managed access operating.
    The first 2 entries are for normal access, the next two show what a time managed record looks like.

        0     0 ACCEPT  tcp  --  *      *       192.168.10.250       0.0.0.0/0           tcp spts:1024:65535 dpts:1:65535 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       192.168.10.250       0.0.0.0/0           udp spts:1024:65535 dpts:1:65535 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       192.168.10.251       0.0.0.0/0           tcp spts:1024:65535 dpts:1:65535 TIME from 23:10 on Fri ACCEPT 
        0     0 ACCEPT  udp  --  *      *       192.168.10.251       0.0.0.0/0           udp spts:1024:65535 dpts:1:65535 TIME from 23:10 on Fri ACCEPT

    Next, do any of your family/relatives have a automated logon (VPN) setup for each day? Does this occur everyday or just weekdays?
    Check the processor load and the processes running at the time. You might need to logon to the terminal and run "top" to see what proces if any is maybe misbehaving. Have you re-booted the system recently?
    FInally, if you get your packfilter rules wrong ( I know from experience) you can get some very strange access issues.

    Ian M
    (edited a number of times)
  • 0 in reply to RFCat_vk_01
    Hello
    First: I have tried reboot. It does not help.

    I was home this morning when I got a message that the line was down. I then immediately connected to my network (this was done from home). From inside I did not notice anything, I went online immediately. As soon as I logged on, the firewall also opened for incoming requests.
    Strange or what?
    PS! Remember that when my firewall is unavailable, it is not pingable either

    You asked me to look at packet filter. I have dumped some of it below, but there are alot of them, so I do not know which of them matters most.

    I'm now heading in 2 directions:

    1. It is a hardware problem in the firewall 
    2. There are automatic routing rules/packet filters that are updated only on outgoing traffic and therefore after a certain idletime are removed and firewall becomes unavailable.

    NOTE! I'm using a 255.255.0.0 subnetmask on my local LAN. This is because I have n subnets locally. 
    I also replaced my public IP address with X.X.X.X
    192.168.Y.Y are a local server
    10.33.56.0 is my IP Sec pool


    Chain AUTO_FORWARD (1 references)
     pkts bytes target     prot opt in     out     source               destination         

    Chain AUTO_INPUT (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 ACCEPT  tcp  --  *      *       192.168.Y.Y          0.0.0.0/0           tcp spts:1:65535 dpt:22 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp spts:1:65535 dpt:22 ACCEPT 
        0     0 LOGDROP    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:22 
        0     0 ACCEPT  tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp spts:1024:65535 dpt:443 ACCEPT 
        5   240 ACCEPT  tcp  --  *      *       10.33.56.0/24        0.0.0.0/0           tcp spts:1024:65535 dpt:443 ACCEPT 
        0     0 LOGDROP    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpt:443 
        1   328 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       10.33.56.0/24        0.0.0.0/0           tcp spts:53:65535 dpt:53 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       10.33.56.0/24        0.0.0.0/0           udp spts:53:65535 dpt:53 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp spts:53:65535 dpt:53 ACCEPT 
        8   533 ACCEPT  udp  --  *      *       192.168.0.0/16       0.0.0.0/0           udp spts:53:65535 dpt:53 ACCEPT 
       77  6268 ACCEPT  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 code 0 ACCEPT 
        0     0 LOGDROP    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:25 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:3840 ACCEPT 
        0     0 ACCEPT  esp  --  *      *       0.0.0.0/0            X.X.X.X        esp spis:256:4294967295 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            X.X.X.X        udp spts:1:65535 dpt:500 ACCEPT 
        1   240 ACCEPT  udp  --  *      *       0.0.0.0/0            X.X.X.X        udp spts:1:65535 dpt:4500 ACCEPT 
        1   198 ACCEPT  udp  --  ipsec+ *       0.0.0.0/0            X.X.X.X        udp spts:1024:65535 dpt:1701 ACCEPT 

    Chain AUTO_OUTPUT (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:53:65535 dpt:53 OWNER CMD match named ACCEPT 
       47  3530 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:53:65535 dpt:53 OWNER CMD match named ACCEPT 
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            129.240.12.4        udp spts:1024:65535 dpt:123 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:25 OWNER CMD match exim ACCEPT 
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 dpts:33000:34000 OWNER CMD match netselect ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:80 OWNER CMD match aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:443 OWNER CMD match aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:80 OWNER CMD match pattern_aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:443 OWNER CMD match pattern_aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:21 OWNER CMD match wget ACCEPT 
        0     0 ACCEPT  esp  --  *      *       X.X.X.X         0.0.0.0/0           esp spis:256:4294967295 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       X.X.X.X         0.0.0.0/0           udp spt:500 dpts:1:65535 OWNER CMD match pluto ACCEPT 
        0     0 ACCEPT  udp  --  *      *       X.X.X.X         0.0.0.0/0           udp spt:4500 dpts:1:65535 OWNER CMD match pluto ACCEPT 
        0     0 ACCEPT  tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpt:80 OWNER CMD match ez-ipupdate ACCEPT 

    Hope this dont reveal to much of my firewall settings. In a few hours I'm hacked [:O]
Reply
  • 0 in reply to RFCat_vk_01
    Hello
    First: I have tried reboot. It does not help.

    I was home this morning when I got a message that the line was down. I then immediately connected to my network (this was done from home). From inside I did not notice anything, I went online immediately. As soon as I logged on, the firewall also opened for incoming requests.
    Strange or what?
    PS! Remember that when my firewall is unavailable, it is not pingable either

    You asked me to look at packet filter. I have dumped some of it below, but there are alot of them, so I do not know which of them matters most.

    I'm now heading in 2 directions:

    1. It is a hardware problem in the firewall 
    2. There are automatic routing rules/packet filters that are updated only on outgoing traffic and therefore after a certain idletime are removed and firewall becomes unavailable.

    NOTE! I'm using a 255.255.0.0 subnetmask on my local LAN. This is because I have n subnets locally. 
    I also replaced my public IP address with X.X.X.X
    192.168.Y.Y are a local server
    10.33.56.0 is my IP Sec pool


    Chain AUTO_FORWARD (1 references)
     pkts bytes target     prot opt in     out     source               destination         

    Chain AUTO_INPUT (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 ACCEPT  tcp  --  *      *       192.168.Y.Y          0.0.0.0/0           tcp spts:1:65535 dpt:22 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp spts:1:65535 dpt:22 ACCEPT 
        0     0 LOGDROP    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:22 
        0     0 ACCEPT  tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp spts:1024:65535 dpt:443 ACCEPT 
        5   240 ACCEPT  tcp  --  *      *       10.33.56.0/24        0.0.0.0/0           tcp spts:1024:65535 dpt:443 ACCEPT 
        0     0 LOGDROP    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpt:443 
        1   328 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       10.33.56.0/24        0.0.0.0/0           tcp spts:53:65535 dpt:53 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       10.33.56.0/24        0.0.0.0/0           udp spts:53:65535 dpt:53 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp spts:53:65535 dpt:53 ACCEPT 
        8   533 ACCEPT  udp  --  *      *       192.168.0.0/16       0.0.0.0/0           udp spts:53:65535 dpt:53 ACCEPT 
       77  6268 ACCEPT  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 code 0 ACCEPT 
        0     0 LOGDROP    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:25 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:3840 ACCEPT 
        0     0 ACCEPT  esp  --  *      *       0.0.0.0/0            X.X.X.X        esp spis:256:4294967295 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            X.X.X.X        udp spts:1:65535 dpt:500 ACCEPT 
        1   240 ACCEPT  udp  --  *      *       0.0.0.0/0            X.X.X.X        udp spts:1:65535 dpt:4500 ACCEPT 
        1   198 ACCEPT  udp  --  ipsec+ *       0.0.0.0/0            X.X.X.X        udp spts:1024:65535 dpt:1701 ACCEPT 

    Chain AUTO_OUTPUT (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:53:65535 dpt:53 OWNER CMD match named ACCEPT 
       47  3530 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:53:65535 dpt:53 OWNER CMD match named ACCEPT 
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            129.240.12.4        udp spts:1024:65535 dpt:123 ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:25 OWNER CMD match exim ACCEPT 
        0     0 ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 dpts:33000:34000 OWNER CMD match netselect ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:80 OWNER CMD match aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:443 OWNER CMD match aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:80 OWNER CMD match pattern_aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:443 OWNER CMD match pattern_aus ACCEPT 
        0     0 ACCEPT  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1:65535 dpt:21 OWNER CMD match wget ACCEPT 
        0     0 ACCEPT  esp  --  *      *       X.X.X.X         0.0.0.0/0           esp spis:256:4294967295 ACCEPT 
        0     0 ACCEPT  udp  --  *      *       X.X.X.X         0.0.0.0/0           udp spt:500 dpts:1:65535 OWNER CMD match pluto ACCEPT 
        0     0 ACCEPT  udp  --  *      *       X.X.X.X         0.0.0.0/0           udp spt:4500 dpts:1:65535 OWNER CMD match pluto ACCEPT 
        0     0 ACCEPT  tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpt:80 OWNER CMD match ez-ipupdate ACCEPT 

    Hope this dont reveal to much of my firewall settings. In a few hours I'm hacked [:O]
Children
  • 0 in reply to marton
    Marton,
    a couple of observations. You seem to have all outgoing ports open. There are no rules that come and go as traffic requires then unless you have time managed aces active and configured. Some lesser used rules might be swapped out, but never removed, so all you would see is a slow response (but only for the first packet) the first time the packet was sent.

    I am trying to be logical ion this investigation, hopefully someone a little wiser to these issues will join in and provide some expertise.

    Some basic configuration questions.

    1/. how is you ASG connected to the internet
    2/. does it have the ADSL connection
    3/. do you have modem that does the ADSL interface and provides you with a ethernet connection eg like a Netgear DG834G modem/router?

    From what you have just described below I suspect you have a modem/router which is setup for connect on request, rather than connect always. During the day there is probably sufficient traffic to keep the connection up, but at night nothing, so no incoming traffic can make the connection.

    This is probably the last thing I can suggest.

    Ian M
  • 0 in reply to RFCat_vk_01
    I know I have outbound firewall open..
    Simplcity over configuration :-)

    I have a fiber connection with static IP. 
    It is always on (or at least it should be)

    I have registered a support ticket with my broadband supplier to have them check my Fiber-converter.
    The fiberconverter is a box with, phone, tv and internet.

    /MartOn
  • 0 in reply to marton
    Hope this dont reveal to much of my firewall settings. In a few hours I'm hacked [:O]
    You should be able to reveal all of your firewall settings and still avoid being hacked, otherwise you have a hole in your firewall configuration. [;)]
  • 0 in reply to drees
    Hello
    Maybe new heading in the "investigation".

    I'm now suspecting that it may be a ARP Cache problem between my fiberterminator box and my Astaro firewall.

    Theory now is that after a given time of inactivitiy the ARP cache is cleared and traffice is not sent.

    This morning I had line problems again I logged into my internal Linux server from a separate internet connection. As soon as I did that, and generated traffic the line was back up.

    Any1 else who has experience from this.

    /MartOn
  • 0 in reply to marton
    MartOn,
    A suggestion that might overcome the potentiual timeout issue.

    How often do you have the ASG run the up2date service. Try changing it to update every hour, in actual practice because there are a couple of different sites involved it actually runs a bit more often than that.

    Ian M