Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 1046 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

Loosing packages between 2 interfaces after update

sHiftY
Hi all,
we have a strange problem with one of our firewalls. After we upgraded the firewall to version 4 (we reinstalled the whole system and loaded the backup) we are loosing all packages between eth0 and eth3.
eth0 172.xx.5.1 netmask 255.255.255.0
eth3 172.xx.3.1 netmask 255.255.255.0
If I for example ping from one host in the 172.xx.5.0 another host in the 172.xx.3.0 the packet is going in to eth0 but not out on eth3 and the packet is not being dropped. For debugging purposes I installed tcpdump on it.
The hosts are even not able to ping the firewall it self from other networks or over the VPN it's working.
But now to the really strange thing, you're able to connect to everywhere else even to the internet from all hosts in this networks.
We checked every logfile, tried another network interface, but nothing helped. Befor the update to version 4 everything was working fine.

We're now out of ideas. [:(]

Has anybody a clue what it could be?

Thanks a lot,
Nils   


This thread was automatically locked due to age.
Parents
  • 0
    I had a similar problem.  check your  pci device id under interfaces.

    see this  thread 


    This may or may not be the solution, but I would check it. 
  • 0 in reply to uncue75
    Mmh, the interfaces list looks strange. But seems to be normal on Astaro 4.015, because we have another 4.015 firewall and there it's the same. On 4.007 everything looks normal. [:S]
    Has it something todo with the kernel update?

    eth0 
    [unknown vendor / unknown chipset] 
    irq=21   mac=00:50:8B:E8:25:BB   type=eth   
     
    eth1
    [unknown vendor / unknown chipset] 
    irq=22   mac=00:50:8B:E8:25:BC   type=eth   
     
    eth2
    [unknown vendor / unknown chipset] 
    irq=16   mac=00:00[[[[:D]]]]1:EF:7F:95   type=eth   
     
    eth3
    [unknown vendor / unknown chipset] 
    irq=17   mac=00:00[[[[:D]]]]1:EF:7F:96   type=eth   
     
    eth4
    [unknown vendor / unknown chipset] 
    irq=18   mac=00:00[[[[:D]]]]1:EF:7F:97   type=eth   
     
    eth5
    [unknown vendor / unknown chipset] 
    irq=19   mac=00:00[[[[:D]]]]1:EF:7F:98   type=eth   


    And slowly it's getting urgent, because this firewall is in Australia and they need the connection between both networks.

    Thanks for all your help,
    Nils  
Reply
  • 0 in reply to uncue75
    Mmh, the interfaces list looks strange. But seems to be normal on Astaro 4.015, because we have another 4.015 firewall and there it's the same. On 4.007 everything looks normal. [:S]
    Has it something todo with the kernel update?

    eth0 
    [unknown vendor / unknown chipset] 
    irq=21   mac=00:50:8B:E8:25:BB   type=eth   
     
    eth1
    [unknown vendor / unknown chipset] 
    irq=22   mac=00:50:8B:E8:25:BC   type=eth   
     
    eth2
    [unknown vendor / unknown chipset] 
    irq=16   mac=00:00[[[[:D]]]]1:EF:7F:95   type=eth   
     
    eth3
    [unknown vendor / unknown chipset] 
    irq=17   mac=00:00[[[[:D]]]]1:EF:7F:96   type=eth   
     
    eth4
    [unknown vendor / unknown chipset] 
    irq=18   mac=00:00[[[[:D]]]]1:EF:7F:97   type=eth   
     
    eth5
    [unknown vendor / unknown chipset] 
    irq=19   mac=00:00[[[[:D]]]]1:EF:7F:98   type=eth   


    And slowly it's getting urgent, because this firewall is in Australia and they need the connection between both networks.

    Thanks for all your help,
    Nils  
Children
  • 0 in reply to sHiftY
    sHifty,

    what was the version before you have applied the up2dated and which on which version is the firewall now?
    Which type of networkcards are installed? If you don't know, please check /etc/modules.conf and report the driver modules. Did you check the kernel log for suspicious entries like netdev errors or dropped packets? Since the Up2Date doesn't change the configuration i don't expect filter entries. 

    UPPPPS you were on 4.007 and now you are on 4.015, this means that there was a kernelupdate meanwhile. The new kernel comes with APIC support and this seems to affect your system -> see the high IRQs at the interfaces. Please see https://community.sophos.com/products/unified-threat-management/astaroorg/f/98/t/68247

    read u
    o|iver 

      
  • 0 in reply to sHiftY
    now that I don't know.  I'm at a loss.  I've only been using astaro for about a week, so maybe someone else can shed some light on what's going on. 
  • 0 in reply to oliver.desch
    Hi Oliver,
    thanks a lot for your help. The firewall was running version 3 the whole time. Then on thursday we installed it with version 4 again, loaded the backup and applied all patches.
    I don't know if it was working without the patches, because after we loaded the backup we installed all patches and then we tested.

    Mmh, the APIC was already disabled:

    fw:/emergency/boot/etc # cat lilo.conf 
    # lilo start: lilo -r /emergency/boot
    boot=/dev/hde
    lba32
    install=/boot/boot-text.b
    vga = normal
    read-only
    message=/etc/astaro-boot-log991211
    prompt
    # for headless machines: remove the comment below
    # to have lilo prompt on first serial port
    #serial=0,9600n8
    timeout=60
    image = /bzImage
        initrd = /initrd
        root = /dev/hde7
        label = default
        append = "acpi=off"
        restricted
    fw:/emergency/boot/etc #

    fw:/emergency/boot/etc # cat /etc/modules.conf 
    alias eth0 e100
    alias eth1 e100
    alias eth2 starfire
    alias eth3 starfire
    alias eth4 starfire
    alias eth5 starfire
    fw:/emergency/boot/etc # 

    There are no errors and dropped packages in the kernel logfile.

    I don't know if the lilo.conf is actual installed one in the bootloader, so i reinstalled lilo with the actual lilo.conf without APIC support.
    Hopefully it works, but I have to wait until tomorrow when somebody is in our Sydney office.

    Thanks for that hint,
    Nils