[Ipsec-tools-users] Double latency in one direction

[Chris Dos <chris@ch...>]

I've been trying to figure this out for a few days know, but I'm at a loss.  Time to ask the experts.

I have two Debian Squeeze boxes that I'm creating a site to site vpn for.

Followed this how to: http://wiki.debian.org/IPsec

I can ping both sides of the internal interfaces, but pings from one side, have twice the latency of the other
side.  I'm at a total loss about why this is occurring.

Site Office Network:
External Interface on eth0: 50.194.128.49/28
Internal Interface on eth1: 172.18.38.1/24
ip route add to 172.18.108.0/24 via 50.194.128.49 src 172.18.38.1


Site Branch Network:
External Interface on eth0: 71.33.229.33/28
Internal Interface on eth1: 172.18.108.1/24
ip route add to 172.18.38.0/24 via 71.33.229.33 src 172.18.108.1


Site Office /etc/racoon/racoon.conf:
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";


remote 71.33.229.33 {
        exchange_mode main,aggressive;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}

sainfo address 172.18.38.0/24 any address 172.18.108.0/24 any {
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}



Site Branch  /etc/racoon/racoon.conf:
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

remote 50.194.128.49 {
        exchange_mode main,aggressive;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}

sainfo address 172.18.108.0/24 any address 172.18.38.0/24 any {
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}



Site Office /etc/ipsec-tools.conf:
flush;
spdflush;

spdadd 172.18.38.0/24 172.18.108.0/24 any -P out ipsec
           esp/tunnel/50.194.128.49-71.33.229.33/require;

spdadd 172.18.108.0/24 172.18.38.0/24 any -P in ipsec
           esp/tunnel/71.33.229.33-50.194.128.49/require;


Site Branch /etc/ipsec-tools.conf:
flush;
spdflush;

spdadd 172.18.108.0/24 172.18.38.0/24 any -P out ipsec
           esp/tunnel/71.33.229.33-50.194.128.49/require;

spdadd 172.18.38.0/24 172.18.108.0/24 any -P in ipsec
           esp/tunnel/50.194.128.49-71.33.229.33/require;



Ping from Office to Branch External:
ping -c5 -n voipshinn
PING voipshinn (71.33.229.33) 56(84) bytes of data.
64 bytes from 71.33.229.33: icmp_req=1 ttl=52 time=70.4 ms
64 bytes from 71.33.229.33: icmp_req=2 ttl=52 time=70.7 ms
64 bytes from 71.33.229.33: icmp_req=3 ttl=52 time=84.5 ms
64 bytes from 71.33.229.33: icmp_req=4 ttl=52 time=70.6 ms
64 bytes from 71.33.229.33: icmp_req=5 ttl=52 time=69.8 ms

Ping from Office to Branch Iternal:
ping -c5 -n voipshinn-int
PING voipshinn-int (172.18.108.1) 56(84) bytes of data.
64 bytes from 172.18.108.1: icmp_req=1 ttl=64 time=84.3 ms
64 bytes from 172.18.108.1: icmp_req=2 ttl=64 time=85.1 ms
64 bytes from 172.18.108.1: icmp_req=3 ttl=64 time=77.8 ms
64 bytes from 172.18.108.1: icmp_req=4 ttl=64 time=78.2 ms
64 bytes from 172.18.108.1: icmp_req=5 ttl=64 time=79.0 ms

So about the same latency from the Office to the Branch.



Ping from Branch to Office External:
ping -c5 -n linuxgw
PING linuxgw (50.194.128.49) 56(84) bytes of data.
64 bytes from 50.194.128.49: icmp_req=1 ttl=51 time=70.9 ms
64 bytes from 50.194.128.49: icmp_req=2 ttl=51 time=71.6 ms
64 bytes from 50.194.128.49: icmp_req=3 ttl=51 time=70.4 ms
64 bytes from 50.194.128.49: icmp_req=4 ttl=51 time=70.2 ms
64 bytes from 50.194.128.49: icmp_req=5 ttl=51 time=69.4 ms

Ping from Branch to Office Internal:
ping -c5 -n linuxgw-int
PING linuxgw-int (172.18.38.1) 56(84) bytes of data.
64 bytes from 172.18.38.1: icmp_req=1 ttl=64 time=139 ms
64 bytes from 172.18.38.1: icmp_req=2 ttl=64 time=134 ms
64 bytes from 172.18.38.1: icmp_req=3 ttl=64 time=133 ms
64 bytes from 172.18.38.1: icmp_req=4 ttl=64 time=134 ms
64 bytes from 172.18.38.1: icmp_req=5 ttl=64 time=136 ms

Pretty much double the latency going over the VPN compared to just pinging the external interface directly.


I can find no reason why this is occurring.  Anyone have any ideas why this is happening?


	Chris

[Ipsec-tools-users] 网站建设，网页设计，网站推广(价格优惠，先制作后付款）

[minpj <minpj@ch...>]

专业承接网站建设，网页设计，网站推广等相关业务，五年专业经验精通各款网页设计软件及ASP数据库，苏州本地人信誉保证，先制作后付款。
常规企业型：2000元/套（包括域名+服务器空间+网页设计），其它数据库要求价格另议。
详情请见：http://%{CURRENT_RANDOMCON1}www.sz9home.com
联系咨询方式：QQ 1261791（加好友时请注明网站咨询） 希清   电话：13914094050 闵小姐
 

[Ipsec-tools-users] setkey key length

[andreas graeper <agraeper@go...>]

hi,
key length for i.e. 3des-cbc 192 > 24 byte > 48 hex figures
but in setkey-script the key-string ist 24 characters ('unvalid key'
when i tried char[48] and 0x[0-9a-f]{48} the same).
first idea: a char in a string is represented by 8bit, but if only
printable values or actually only hex-figures are respected, there are
lots of unusable keys ?

in a tutorial i found 'dd if=/dev/random count=24 bs=1 2>/dev/null |
xxd -ps' but this gives (as expected) a hex-string of length 48. whats
wrong ?
ag