Guest User!

You are not Sophos Staff.

[CONFIRMED] [7.350] openvpn automatic packet filter not working ?

Hi

just succeeded into running openvpn client (site-to-site) from my asg box (after fixing the missing libs)... but seems there are missing rules to make it work:

from within the asg box it works:

asg:/root # ping -n -c 3 10.0.0.100
PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
64 bytes from 10.0.0.100: icmp_seq=1 ttl=63 time=77.5 ms
64 bytes from 10.0.0.100: icmp_seq=2 ttl=63 time=72.0 ms
64 bytes from 10.0.0.100: icmp_seq=3 ttl=63 time=80.9 ms

--- 10.0.0.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 72.083/76.856/80.982/3.661 ms


but not from my desktop box


[11:05:17] root@beyond - ~> ping -n -c 3 10.0.0.100
PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.

--- 10.0.0.100 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2012ms


I checked both openvpn config on the server and client and config it twice to be sure that I checked "automatic packet filtering"... and still does not work..

thx
  • Could you please check in /var/log/packetfilter.log if the packets are dropped. Thanks!
  • Could you please check in /var/log/packetfilter.log if the packets are dropped. Thanks!


    there is nothing special [:(]

    and I just did a fresh install on a new box (not a vmware nor alix board) and configured everything from zero...

    only thing I get is:


    2008:11:28-17:42:51 (none) ulogd[3194]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth0" outitf="eth0" dstmac="00:13[:D]3:ce:3f:4c" srcmac="00:00:00:00:00:00" srcip="1.1.1.1" dstip="224.0.0.1" proto="2" length="32" tos="0x00" prec="0xc0" ttl="1" 
    2008:11:28-17:43:59 (none) ulogd[3194]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth0" outitf="eth0" dstmac="00:13[:D]3:ce:3f:4c" srcmac="00:00:00:00:00:00" srcip="1.1.1.1" dstip="224.0.0.1" proto="2" length="32" tos="0x00" prec="0xc0" ttl="1" 


    I can open an access to you if needed ? or I can send you my apc file ...

    thx

    edit1: for info I've no IPS activated, no web proxy or whatever... just openvpn client, packet filter rule to allow internal -> any, and masquerading for internal network on external interface
  • FWrule > 60000 means IP/P2P-Protection. You could try to disable this...
  • FWrule > 60000 means IP/P2P-Protection. You could try to disable this...


    IM and P2P are also disabled ! I mean Control is disabled
  • Just to clarify things: Do you use Site-to-Site VPN or Remote Access VPN on the ASG?
  • Just to clarify things: Do you use Site-to-Site VPN or Remote Access VPN on the ASG?


    as I said this is site-to-site openvpn on asg (client/server)
  • Could you please post the output of `iptables -L AUTO_FORWARD -nv` on both client and server after the site-to-site connection has been established.
  • here are the results:

    on the server:


    asg:/root # iptables -L AUTO_FORWARD -nv
    Chain AUTO_FORWARD (1 references)
     pkts bytes target     prot opt in     out     source               destination         
      140 11760 CONFIRMED  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 code 0 CONFIRMED 
        0     0 CONFIRMED  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 0 code 0 CONFIRMED 
        2   160 CONFIRMED  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 dpts:33000:34000 CONFIRMED 
        0     0 CONFIRMED  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 11 code 0 CONFIRMED 
       14   852 CONFIRMED  all  --  ipsec+ *       172.18.0.0/16        10.0.0.0/8          CONFIRMED 
      106  6015 CONFIRMED  all  --  *      ipsec+  10.0.0.0/8           172.18.0.0/16       CONFIRMED 
        0     0 CONFIRMED  all  --  ipsec+ *       192.168.2.0/24       10.0.0.0/8          CONFIRMED 
        0     0 CONFIRMED  all  --  *      ipsec+  10.0.0.0/8           192.168.2.0/24      CONFIRMED 
        0     0 CONFIRMED  all  --  tun1   *       192.168.1.0/24       10.0.0.0/8          CONFIRMED 
        0     0 CONFIRMED  all  --  *      tun1    10.0.0.0/8           192.168.1.0/24      CONFIRMED 
        0     0 CONFIRMED  tcp  --  *      eth0    0.0.0.0/0            10.0.0.100          tcp spts:1:65535 dpt:53 ctorigdst 213.x.y.106 CONFIRMED 
       53  3884 CONFIRMED  udp  --  *      eth0    0.0.0.0/0            10.0.0.100          udp spts:1:65535 dpt:53 ctorigdst 213.x.y.106 CONFIRMED 
        0     0 CONFIRMED  tcp  --  *      eth0    0.0.0.0/0            10.1.1.111          tcp spts:1:65535 dpt:80 ctorigdst 213.x.y.108 CONFIRMED 
        0     0 CONFIRMED  tcp  --  *      eth0    0.0.0.0/0            10.1.1.111          tcp spts:1:65535 dpts:8000:9000 ctorigdst 213.x.y.108 CONFIRMED 


    and onto the client


    iptables -L AUTO_FORWARD -nv
    Chain AUTO_FORWARD (1 references)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 CONFIRMED  all  --  ipsec+ *       192.168.2.0/24       192.168.1.0/24      CONFIRMED 
        0     0 CONFIRMED  all  --  *      ipsec+  192.168.1.0/24       192.168.2.0/24      CONFIRMED 
        0     0 CONFIRMED  all  --  ipsec+ *       172.18.0.0/16        192.168.1.0/24      CONFIRMED 
        0     0 CONFIRMED  all  --  *      ipsec+  192.168.1.0/24       172.18.0.0/16       CONFIRMED 
        0     0 CONFIRMED  all  --  tun0   *       10.0.0.0/8           192.168.1.0/24      CONFIRMED 
        1    84 CONFIRMED  all  --  *      tun0    192.168.1.0/24       10.0.0.0/8          CONFIRMED 
       10   484 CONFIRMED  tcp  --  *      *       0.0.0.0/0            192.168.1.2         tcp spts:1:65535 dpt:51413 ctorigdst 79.x.y.222 CONFIRMED 


    thx
  • Packet filter rules allowing traffic between 192.168.1.0/24 and 10.0.0.0/8 are in place, so this might be caused by s.th. else. Do the echo-request packets show up when you run tcpdump on the 192.168.1.x eth interface on the client? If yes, how about on the tunX interface on the server?
  • Here are the results:

    on the client:


    asg:/root # tcpdump -qni eth1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
    13:01:21.344406 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 57, length 64
    13:01:22.344236 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 58, length 64
    13:01:23.344253 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 59, length 64


    and on the server:


    asg:/root # tcpdump -qni tun0 icmp
    tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
    13:03:12.826918 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 169, length 64
    13:03:13.828837 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 170, length 64
    13:03:14.826987 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 171, length 64
    13:03:15.826930 IP 192.168.1.2 > 10.0.0.1: ICMP echo request, id 51002, seq 172, length 64


    10.0.0.1 is the ip on the internal interface on the server...

    I also tried with 10.0.0.100 which is a box in the network on the server side..

    for info I've also a Remote SSL VPN which is working fine from my local desktop when I activate it !