Hi Daniel,

Thank you very much, I'm going to use VPN on different box because I have IP-PBX
installed in this box and may be kernel upgrade will effect the voice 
functionality and
patch the strongswan not trusted.

Finlay nice to deal with Daniel and your help is really appreciated.   

--
Best Regards
Walid Aweiwi
Systems Engineer
Network Department
Bisan Systems Ltd.
Tel    +97222985941 ext 202
Fax    +97222985942
Mobile +972599673507 
http://www.bisan.com
http://www.bisan.ps

---------- Original Message -----------
From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com>
To: Walid Aweiwi <wa...@bisan.com>
Cc: users@lists.strongswan.org
Sent: Fri, 02 Jan 2009 18:47:27 +0100
Subject: Re: [strongSwan] Problem with ikev1 net2net-psk,       both VPN 
servers are behind NAT

> Hi Walid,
> 
> to me it seems that your problem is related to the one described in
> 
> https://lists.strongswan.org/pipermail/users/2008-September/002705.html
> 
> The only thing I can suggest is to upgrade your kernel or to apply the 
> patch that was posted in the e-mail mentioned above. But be aware that 
> this patch might break other features of strongSwan.
> 
> I would go for the first option if possible: Upgrade the kernel.
> 
> Regards,
>   Daniel
> 
> Walid Aweiwi wrote:
> > Hi Daniel,
> > 
> > Exactly I have CentOS5/RHEL5 machine, actually it is a trixbox 2.6.13, is 
> > this my
problem?
> > 
> > ip xfrm monitor
> > 
> > 
> > 
> > Deleted src 192.168.14.1 dst 82.102.240.47
> >         proto esp spi 0x6909a1ff reqid 16385 mode tunnel
> >         replay-window 32 
> >         auth sha1 0xfea69a74cab82ffbd8d34456f8e7c80ee2a40873
> >         enc aes 0xbe25c4cfb9248829fec842d816684234
> >         encap type espinudp sport 4500 dport 10559 addr 0.0.0.0
> > Deleted src 82.102.240.47 dst 192.168.14.1
> >         proto esp spi 0xf40155fb reqid 16385 mode tunnel
> >         replay-window 32 
> >         auth sha1 0x444138c885b07307d384a66367566db0e61f3c42
> >         enc aes 0x15cfdeaff19184eb252aff99ce34e115
> >         encap type espinudp sport 10559 dport 4500 addr 0.0.0.0
> > 
> > 
> > --
> > Best Regards
> > Walid Aweiwi
> > Systems Engineer
> > Network Department
> > Bisan Systems Ltd.
> > Tel    +97222985941 ext 202
> > Fax    +97222985942
> > Mobile +972599673507 
> > http://www.bisan.com
> > http://www.bisan.ps
> > 
> > ---------- Original Message -----------
> > From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com>
> > To: Walid Aweiwi <wa...@bisan.com>
> > Cc: users@lists.strongswan.org
> > Sent: Fri, 02 Jan 2009 16:18:10 +0100
> > Subject: Re: [strongSwan] Problem with ikev1 net2net-psk,   both VPN 
> > servers are
behind NAT
> > 
> >> Hi Walid,
> >>
> >> I must admit that I still have no idea what the reason for this problem is.
> >>
> >> But I found a message on this mailing list in which a very similar 
> >> problem is described:
> >>
> >> https://lists.strongswan.org/pipermail/users/2008-February/002258.html
> >>
> >> The author was using a CentOS5/RHEL5 machine. Are you using the same 
> >> distribution?
> >>
> >> He says that the command "ipsec status" deletes entries in the SPD.
> >> Could you please run "ip xfrm policy" before executing "ipsec status"? 
> >> Also please run "ip xfrm monitor" while you're running strongSwan. "ip 
> >> xfrm monitor" is like "tail -f". It prints all the changes that were 
> >> made to the SPD. So you need to run this on a separate tty while you're 
> >> starting strongSwan.
> >>
> >> Please send us the output of "ip xfrm monitor".
> >>
> >> Daniel
> >>
> >> Walid Aweiwi wrote:
> >>> Hi Daniel,
> >>>
> >>> I forgot to mentioned that I'm using virtual interface (eth0, eth0:1) not 
> >>> two
NICs, eth0
> >>> is the WAN "external" NIC and the eth0:1 is the LAN "internal" NIC.
> >>>
> >>> --
> >>> Best Regards
> >>> Walid Aweiwi
> >>> Systems Engineer
> >>> Network Department
> >>> Bisan Systems Ltd.
> >>> Tel    +97222985941 ext 202
> >>> Fax    +97222985942
> >>> Mobile +972599673507 
> >>> http://www.bisan.com
> >>> http://www.bisan.ps
> >>>
> >>> ---------- Original Message -----------
> >>> From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com>
> >>> To: Walid Aweiwi <wa...@bisan.com>
> >>> Cc: users@lists.strongswan.org
> >>> Sent: Fri, 02 Jan 2009 13:14:12 +0100
> >>> Subject: Re: [strongSwan] Problem with ikev1 net2net-psk, both VPN 
> >>> servers are
> > behind NAT
> >>>> Hi Walid,
> >>>>
> >>>> thanks for the debug output.
> >>>> The command "ip xfrm policy" printed the contents of the so called 
> >>>> Security Policy Database or SPD. To me it seems that the correct entries 
> >>>> are missing in this database. It's over my head why those entries are 
> >>>> missing. Also, the routing table misses necessary entries as well.
> >>>>
> >>>>  From the tcpdump output you provided I can see that the packets are not 
> >>>> encrypted which is a consequence of the fact that those SPD entries are 
> >>>> missing.
> >>>>
> >>>> I would like to ask you again to provide additional data: You enabled
> >>>>
> >>>> plutodebug=control
> >>>>
> >>>> which is a good thing. Could you please provide us with the data from 
> >>>> the syslog output. This is in /var/log/auth.log on my debian system but 
> >>>> it might be located in a different file depending on your distribution. 
> >>>> I'm interested in the lines containing "pluto[xxxx]".
> >>>>
> >>>> Thanks
> >>>>   Daniel
> >>>>
> >>>> Walid Aweiwi wrote:
> >>>>> Hi Daniel,
> >>>>>
> >>>>> RED output logs:
> >>>>> ip route list
> >>>>> 192.168.100.0/24 dev eth0  proto kernel  scope link  src 
> >>>>> 192.168.100.100 
> >>>>> 192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.254 
> >>>>> 169.254.0.0/16 dev eth0  scope link 
> >>>>> default via 192.168.2.1 dev eth0 
> >>>>>
> >>>>> ipsec status
> >>>>> 000 "net-net":
> >>>>>
> >
192.168.100.0/24===192.168.2.254:45...@moon.strongswan.org]...213.6.10.244:45...@sun.strongswan.org]===192.168.25.0/24;
> >>>>> erouted; eroute owner: #4
> >>>>> 000 "net-net":   newest ISAKMP SA: #3; newest IPsec SA: #4; 
> >>>>> 000 
> >>>>> 000 #2: "net-net" STATE_QUICK_I2 (sent QI2, IPsec SA established); 
> >>>>> EVENT_SA_REPLACE
> >>> in 722s
> >>>>> 000 #2: "net-net" esp.a1da8...@213.6.10.244 (0 bytes) 
> >>>>> esp.70034...@192.168.2.254 (0
> >>>>> bytes); tunnel
> >>>>> 000 #1: "net-net" STATE_MAIN_I4 (ISAKMP SA established); 
> >>>>> EVENT_SA_REPLACE in 3136s
> >>>>> 000 #4: "net-net" STATE_QUICK_R2 (IPsec SA established); 
> >>>>> EVENT_SA_REPLACE in 871s;
> >>>>> newest IPSEC; eroute owner
> >>>>> 000 #4: "net-net" esp.c1322...@213.6.10.244 (0 bytes) 
> >>>>> esp.c5b53...@192.168.2.254;
> > tunnel
> >>>>> 000 #3: "net-net" STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in
> >>>>> 3271s; newest ISAKMP
> >>>>> 000 
> >>>>>
> >>>>> ip xfrm policy
> >>>>> src ::/0 dst ::/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src ::/0 dst ::/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>>
> >>>>> ip xfrm state
> >>>>> src 213.6.10.244 dst 192.168.2.254
> >>>>>         proto esp spi 0xc5b532b7 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x5c0a3d0f315b36ad2210bbabfe90202ea27a9012
> >>>>>         enc aes 0xaee1287ed6439f8f7f06e9608a3bc044
> >>>>>         encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> >>>>> src 213.6.10.244 dst 192.168.2.254
> >>>>>         proto esp spi 0x700349d6 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x127407c58db393cffcbfdea180fa8d5018bac1d4
> >>>>>         enc aes 0xa477d0b7b8393a8ccd643f43a4f379d6
> >>>>>         encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> >>>>> src 192.168.2.254 dst 213.6.10.244
> >>>>>         proto esp spi 0xc13228b8 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x9ca5f62b66e851411b0e7304533f510d2ed81f55
> >>>>>         enc aes 0xfe00b0f04372a74c1f8a0fd5e732e8ce
> >>>>>         encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> >>>>> src 192.168.2.254 dst 213.6.10.244
> >>>>>         proto esp spi 0xa1da8e02 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x8fee90346508a1cf1e4a3fc7f194ec1563223eb6
> >>>>>         enc aes 0x99188eda96220f3faad60b9bd6bbf717
> >>>>>         encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> BLUE output logs:
> >>>>>
> >>>>> ip route list
> >>>>> 192.168.14.0/24 dev eth0  proto kernel  scope link  src 192.168.14.1 
> >>>>> 192.168.25.0/24 dev eth0  proto kernel  scope link  src 192.168.25.25 
> >>>>> 169.254.0.0/16 dev eth0  scope link 
> >>>>> default via 192.168.14.254 dev eth0 
> >>>>>
> >>>>> ipsec status
> >>>>> 000 "net-net":
> >>>>>
> >
192.168.25.0/24===192.168.14.1:45...@sun.strongswan.org]...82.102.240.47:101...@moon.strongswan.org]===192.168.100.0/24;
> >>>>> erouted; eroute owner: #4
> >>>>> 000 "net-net":   newest ISAKMP SA: #1; newest IPsec SA: #4; 
> >>>>> 000 
> >>>>> 000 #4: "net-net" STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in
> >>>>> 488s; newest IPSEC; eroute owner
> >>>>> 000 #4: "net-net" esp.c5b53...@82.102.240.47 (0 bytes) 
> >>>>> esp.c1322...@192.168.14.1 (0
> >>>>> bytes); tunnel
> >>>>> 000 #1: "net-net" STATE_MAIN_I4 (ISAKMP SA established); 
> >>>>> EVENT_SA_REPLACE in 3011s;
> >>>>> newest ISAKMP
> >>>>> 000 #3: "net-net" STATE_QUICK_R2 (IPsec SA established); 
> >>>>> EVENT_SA_REPLACE in 727s
> >>>>> 000 #3: "net-net" esp.70034...@82.102.240.47 (0 bytes) 
> >>>>> esp.a1da8...@192.168.14.1 (0
> >>>>> bytes); tunnel
> >>>>> 000 #2: "net-net" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
> >>>>> EVENT_SA_REPLACE
> >>> in 3126s
> >>>>> 000 
> >>>>>
> >>>>> src ::/0 dst ::/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir in priority 0 
> >>>>> src ::/0 dst ::/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>> src 0.0.0.0/0 dst 0.0.0.0/0 
> >>>>>         dir out priority 0 
> >>>>>
> >>>>> src 192.168.14.1 dst 82.102.240.47
> >>>>>         proto esp spi 0xc5b532b7 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x5c0a3d0f315b36ad2210bbabfe90202ea27a9012
> >>>>>         enc aes 0xaee1287ed6439f8f7f06e9608a3bc044
> >>>>>         encap type espinudp sport 4500 dport 10171 addr 0.0.0.0
> >>>>> src 192.168.14.1 dst 82.102.240.47
> >>>>>         proto esp spi 0x700349d6 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x127407c58db393cffcbfdea180fa8d5018bac1d4
> >>>>>         enc aes 0xa477d0b7b8393a8ccd643f43a4f379d6
> >>>>>         encap type espinudp sport 4500 dport 10171 addr 0.0.0.0
> >>>>> src 82.102.240.47 dst 192.168.14.1
> >>>>>         proto esp spi 0xc13228b8 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x9ca5f62b66e851411b0e7304533f510d2ed81f55
> >>>>>         enc aes 0xfe00b0f04372a74c1f8a0fd5e732e8ce
> >>>>>         encap type espinudp sport 10171 dport 4500 addr 0.0.0.0
> >>>>> src 82.102.240.47 dst 192.168.14.1
> >>>>>         proto esp spi 0xa1da8e02 reqid 16385 mode tunnel
> >>>>>         replay-window 32 
> >>>>>         auth sha1 0x8fee90346508a1cf1e4a3fc7f194ec1563223eb6
> >>>>>         enc aes 0x99188eda96220f3faad60b9bd6bbf717
> >>>>>         encap type espinudp sport 10171 dport 4500 addr 0.0.0.0
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> the tcpdump logs on RED.
> >>>>>
> >>>>> tcpdump -i eth0 not port ssh and not port domain and not arp
> >>>>>
> >>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> >>>>> decode
> >>>>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> >>>>> 13:15:32.213144 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12
> >>>>> 13:15:32.815520 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
> >>>>> Request from
> >>>>> 00:13:ce:e1:90:39 (oui Unknown), length: 300
> >>>>> 13:15:32.822317 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
> >>>>> Request from
> >>>>> 00:13:ce:e1:90:39 (oui Unknown), length: 326
> >>>>> 13:15:33.214593 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12
> >>>>> 13:15:35.696800 IP 192.168.2.100 > IGMP.MCAST.NET: igmp v3 report, 1 
> >>>>> group record(s)
> >>>>> 13:15:35.733188 IP 192.168.2.100.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): REGISTRATION; REQUEST; BROADCAST
> >>>>> 13:15:41.256312 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:41.256475 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:42.005718 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:42.005887 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:42.756095 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:42.756299 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:43.505142 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:44.255700 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:45.005950 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:15:45.575554 IP a10-244.adsl.paltel.net.ipsec-nat-t > 
> >>>>> 192.168.2.254.ipsec-nat-t:
> >>>>> isakmp-nat-keep-alive
> >>>>> 13:15:46.607604 IP 192.168.2.254.ipsec-nat-t > 
> >>>>> a10-244.adsl.paltel.net.ipsec-nat-t:
> >>>>> isakmp-nat-keep-alive
> >>>>> 13:15:52.214772 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12
> >>>>> 13:15:53.216956 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12
> >>>>> 13:16:00.755893 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:00.756295 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:01.505012 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:01.505198 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:02.255106 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:02.255466 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:03.004167 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:03.753917 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:04.505081 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:05.263502 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:05.592182 IP a10-244.adsl.paltel.net.ipsec-nat-t > 
> >>>>> 192.168.2.254.ipsec-nat-t:
> >>>>> isakmp-nat-keep-alive
> >>>>> 13:16:06.012609 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:06.747796 IP 192.168.2.254.ipsec-nat-t > 
> >>>>> a10-244.adsl.paltel.net.ipsec-nat-t:
> >>>>> isakmp-nat-keep-alive
> >>>>> 13:16:06.761678 IP 192.168.2.101.netbios-ns > 192.168.2.255.netbios-ns: 
> >>>>> NBT UDP
> >>>>> PACKET(137): QUERY; REQUEST; BROADCAST
> >>>>> 13:16:12.218682 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12
> >>>>> 13:16:12.971620 IP 192.168.2.254 > 192.168.25.25: ICMP echo request, id 
> >>>>> 36124,
seq 1,
> >>>>> length 64
> >>>>> 13:16:13.220735 IP 192.168.2.254.iax > 192.168.14.14.iax: UDP, length 12
> >>>>> 13:16:13.971711 IP 192.168.2.254 > 192.168.25.25: ICMP echo request, id 
> >>>>> 36124,
seq 2,
> >>>>> length 64
> >>>>> 13:16:14.972435 IP 192.168.2.254 > 192.168.25.25: ICMP echo request, id 
> >>>>> --
> >>>>> Best Regards
> >>>>> Walid Aweiwi
> >>>>> Systems Engineer
> >>>>> Network Department
> >>>>> Bisan Systems Ltd.
> >>>>> Tel    +97222985941 ext 202
> >>>>> Fax    +97222985942
> >>>>> Mobile +972599673507 
> >>>>> http://www.bisan.com
> >>>>> http://www.bisan.ps
> >>>>>
> >>>>> ---------- Original Message -----------
> >>>>> From: Daniel Mentz <danielml+mailinglists.strongs...@sent.com>
> >>>>> To: Walid Aweiwi <wa...@bisan.com>
> >>>>> Cc: users@lists.strongswan.org
> >>>>> Sent: Fri, 02 Jan 2009 10:26:08 +0100
> >>>>> Subject: Re: [strongSwan] Problem with ikev1 net2net-psk,       both 
> >>>>> VPN servers are
> >>> behind NAT
> >>>>>> Walid Aweiwi wrote:
> >>>>>>  > but my problem is no route nor ping from RED server to BLUE.
> >>>>>>
> >>>>>> Hi Walid,
> >>>>>>
> >>>>>> could you please provide us with the output of the command
> >>>>>>
> >>>>>> ip route list
> >>>>>>
> >>>>>> It should contain something like
> >>>>>>
> >>>>>> 192.168.25.0/24 dev ppp0 scope link  src 192.168.100.100
> >>>>>>
> >>>>>> The outlook will look differently on your machine because you're 
> >>>>>> probably using an ethernet link instead of PPP.
> >>>>>>
> >>>>>> The output of "ipsec status" looks very promising.
> >>>>>> What's the exact output of the ping command? Does it say "no route to 
> >>>>>> host" or is it just not getting any reply (100% packet loss) ?
> >>>>>>
> >>>>>> Please run tcpdump on the external interfaces of RED and BLUE in order 
> >>>>>> to see if those boxes transmit ESP packets or just unencrypted ICMP 
> >>>>>> packets.
> >>>>>>
> >>>>>> For the sake of completeness you could also include the output of the 
> >>>>>> two following commands:
> >>>>>>
> >>>>>> ip xfrm state
> >>>>>> ip xfrm policy
> >>>>>>
> >>>>>> Regards,
> >>>>>>   Daniel
> >>>>>>
> >>>>>> *************
> >>>>>> This  message has been scanned for viruses and dangerous content by 
> >>>>>> Bisan 
> >>>>>> Systems Ltd  MailScanner, and is believed  to be clean.Bisan Systems 
> >>>>>> Ltd  does 
> >>>>>>  not  represent  that  any  attachment  is free from computer viruses 
> >>>>>> or 
> >>>>>> defects and the user assumes all responsibility  for any  loss, damage 
> >>>>>>  or 
> >>>>>>  consequence  resulting  directly  or  indirectly  from  the use of 
> >>>>>> any 
> >>>>>> attachment. The information  contained  in  any  email  does not 
> >>>>>> necessarily 
> >>>>>>  reflect the views of Bisan systems or any other related entities or 
> >>>>>> persons.
> >>>>> ------- End of Original Message -------
> >>>>>
> >>>> *************
> >>>> This  message has been scanned for viruses and dangerous content by 
> >>>> Bisan 
> >>>> Systems Ltd  MailScanner, and is believed  to be clean.Bisan Systems Ltd 
> >>>>  does 
> >>>>  not  represent  that  any  attachment  is free from computer viruses or 
> >>>> defects and the user assumes all responsibility  for any  loss, damage  
> >>>> or 
> >>>>  consequence  resulting  directly  or  indirectly  from  the use of any 
> >>>> attachment. The information  contained  in  any  email  does not 
> >>>> necessarily 
> >>>>  reflect the views of Bisan systems or any other related entities or 
> >>>> persons.
> >>> ------- End of Original Message -------
> >>>
> >> *************
> >> This  message has been scanned for viruses and dangerous content by Bisan 
> >> Systems Ltd  MailScanner, and is believed  to be clean.Bisan Systems Ltd  
> >> does 
> >>  not  represent  that  any  attachment  is free from computer viruses or 
> >> defects and the user assumes all responsibility  for any  loss, damage  or 
> >>  consequence  resulting  directly  or  indirectly  from  the use of any 
> >> attachment. The information  contained  in  any  email  does not 
> >> necessarily 
> >>  reflect the views of Bisan systems or any other related entities or 
> >> persons.
> > ------- End of Original Message -------
> >
> 
> *************
> This  message has been scanned for viruses and dangerous content by Bisan 
> Systems Ltd  MailScanner, and is believed  to be clean.Bisan Systems Ltd  
> does 
>  not  represent  that  any  attachment  is free from computer viruses or 
> defects and the user assumes all responsibility  for any  loss, damage  or 
>  consequence  resulting  directly  or  indirectly  from  the use of any 
> attachment. The information  contained  in  any  email  does not necessarily 
>  reflect the views of Bisan systems or any other related entities or persons.
------- End of Original Message -------

_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to