[7.901][BUG][FIXED] Ipv6 Incoming Packet Filter Problem

Hello, 

I set an incoming packet filter for an ipv6 host in my lan this way : 

Any sources --- ssh service --- my ipv6 host (ipv6 only) , allow and log

But when i try to connect to this ip from an other ipv6 host on internet it's blocked by Default Drop.

I try with different services and differents internet hosts, same problem.
see screen capture for details.
  • Astaro Beta Report
    
    --------------------------------
    Version: 7.901
    Type: BUG
    State: CLOSED/FIXED
    Reporter: Kneissel+++
    Contributor: 
    MantisID: 13335
    Target version: 7.903
    Fixed in version: 7.903
    --------------------------------
  • add on :

    i just test with 7.900 on another appliance, it works perfectly.
    Will upgrade to 7.901 to see if i got the problem too.
  • Upgraded in 7.901, problem is back and i notice a new thing : all outgoing ipv6 seems to go to default Drop

    Configuration should be good because it works fine in 7.900.
  • Please give the output of ip6tables-save before and after enabling the rule.  Thank you!
  • Hello, 

    see results in the zip file as i can't put it directly here (too big txt files).
    result.zip
  • Thanks.  I'm missing the ssh rule in the USR_FORWARD chain In the output you gave.  However, I can't reproduce it currently.  This is the rule I get:

    -A USR_FORWARD -d 20a0::1:2:3:4/128 -p tcp -m tcp --sport 1:65535 --dport 22 -m logmark --logmark 6 -j LOGACCEPT

    You can reduce the output by just running

     ip6tables -L USR_FORWARD

    before and after.

    Also please provide /var/log/mdw.log and /var/log/mdw-debug.log.
  • Hello, 

    fw:/root # ip6tables -L USR_FORWARD
    Chain USR_FORWARD (1 references)
    target     prot opt source               destination
    fw:/root #

    same before and after

    but there's an error in /var/log/mdw-debug.log :

    2010:04:14-17:19:35 fw middleware[3564]: T core::Config::Changed:131() => configversion=46
    2010:04:14-17:19:35 fw middleware[3564]: T core::Config::Changed:141() => nodes=0 objects=1 triggers=0
    2010:04:14-17:19:35 fw middleware[3564]: T core::Config::load:267() => modules=2,1
    2010:04:14-17:19:35 fw middleware[3564]: D core::Config::load:272() => packetfilter.adapter.obj (packetfilter->rules.conf)
    2010:04:14-17:19:36 fw middleware[3564]: ip6tables-restore v1.4.4: unknown option `--icmp-type'
    2010:04:14-17:19:36 fw middleware[3564]: Error occurred at line: 10
    2010:04:14-17:19:36 fw middleware[3564]: Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
    2010:04:14-17:19:36 fw middleware[3564]: 1: *filter
    2010:04:14-17:19:36 fw middleware[3564]: 2:  -F USR_FORWARD

    2010:04:14-17:19:36 fw middleware[3564]: 10:  -A USR_FORWARD -s 2002:***x:***x:31:226:18FF:FE75:80DF/128 -p icmp --icmp-type 8/0 -j CONFIRMED

    2010:04:14-17:19:36 fw middleware[3564]: 32: COMMIT
    2010:04:14-17:19:36 fw middleware[3564]: D utils::Exec::ForkingSystem:99() => CHILD 1 FORK 10692 /usr/local/bin/ipt_clear_confirmed.sh
    2010:04:14-17:19:36 fw middleware[3564]: T main::top-level:194() => ending cycle 23, caught 0 signals
    2010:04:14-17:19:36 fw middleware[3564]: D utils::Exec::BuryChildren:107() => CHILD 1 EXIT 10692 /usr/local/bin/ipt_clear_confirmed.sh

    Problem seem's to be with ping, so i make a little search and find a packet filter allowing my v4/v6 host to do ping, i remove ping and now it works fine.
  • Ok.  Did you define an ICMP (IPv4) Service and used it with that address?  Once I do this it's reproducible here.  Fix for that will be in the next up2date.  Thank you.
  • i set a packet filter like that :

    my host (v4/v6) as source --- any (v4/v6) as destination --- a group of service i made, which contain ping (the one i found in the service liste)

  • Did you define an ICMP (IPv4) Service and used it with that address?


    This will now be prevented.
    You can still use mixed (IPv4+IPv6) network objects with ICMPv4 services or service groups containing ICMPv4 services.
    But using IPv6-only network objects with ICMPv4 services or with service groups containing nothing but ICMPv4 services will now be denied, because that would be in a packetfilter rule object resulting in no netfilter rules whatsoever.