Project

General

Profile

Issue #3270

Can not ping.

Added by zhenxing huang 9 months ago. Updated 9 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.8.1
Resolution:

Description

Hello
There are three interconnected sites that between a-b AND between b-c
My question is when ping intranet of b in a , can't capture packets in a,and received package in b;
when ping intranet of a in b,can't capture packets both a and b
between b-c is good
Below is my configuration and input information of a AND b
And i found it is "ESP in UDP SPIs " of b-c,does it affect?

[root@vps ~]#cat /etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
        strictcrlpolicy=no
        uniqueids = yes
conn  %default
        left=vps.domain.cn
        leftid="C=US, CN=vps.domain.cn" 
        leftfirewall=yes
        keyexchange=ikev2
        dpdaction=clear
        dpddelay=30
        dpdtimeout=60
        rekey=yes
        ike=aes256-sha384-prfsha384-modp1024-curve25519,aes128-sha256-modp2048,aes256-sha256-prfsha256-modp2048,aes256-md5-prfmd5-modp1536,aes256-sha256-sha384-modp1024
        #esp=aes256-md5-modp1536!
        auto=add
conn  eco
        leftid=vps.domain.cn
        leftsubnet=10.76.15.254/32
        leftauth=psk
        right=*.*.*.182
        rightid = m.domain.cn
        rightsubnet=172.27.7.0/24
        rightauth=psk
        leftsendcert=never
        rightsendcert=never

[root@vps ~]# ip route show table 220
172.27.7.0/24 via *.*.160.1 dev eth0  proto static  src 10.76.15.254
10.76.12.0/22 dev eth1  proto static  src 10.76.15.254
*.*.160.0/19 dev eth0  proto static  src *.*.188.145

[root@vps ~]# ipsec status
Shunted Connections:
Bypass LAN 10.76.12.0/22:  10.76.12.0/22 === 10.76.12.0/22 PASS
Bypass LAN *.*.160.0/19:  *.*.160.0/19 === *.*.160.0/19 PASS
Security Associations (1 up, 0 connecting):
         eco[2]: ESTABLISHED 5 minutes ago, *.*.188.145[vps.domain.cn]...*.*.*.182[m.domain.cn]
         eco{1}:  INSTALLED, TUNNEL, reqid 1, *ESP SPIs*: c463be21_i c009bb30_o
         eco{1}:   10.76.15.254/32 === 172.27.7.0/24
[root@eco root]cat /etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
        strictcrlpolicy=no
        uniqueids = yes
conn  %default
        left=m.domain.cn
        leftid=m.domain.cn
        leftcert=m.cer
        leftauth=pubkey
        leftfirewall=yes
        keyexchange=ikev2
        dpdaction=clear
        dpddelay=30
        dpdtimeout=60
        rekey=yes
        ike=aes256-sha384-prfsha384-modp1024-curve25519,aes128-sha256-modp2048,aes256-sha256-prfsha256-modp2048,aes256-md5-prfmd5-modp1536,aes256-sha256-sha384-modp1024
        #esp=aes128-sha256
        auto=add
conn vps
        leftsubnet=172.27.7.0/24
        leftauth=psk
        right=vps.domain.cn
        rightid=vps.domain.cn
        rightsubnet=10.76.15.254/32
        rightauth=psk
        leftsendcert=never
        rightsendcert=never
        auto=start

[root@eco ~]#ip route show table 220
10.76.15.254 via *.*.*.177 dev p4p1  proto static  src 172.27.7.254
*.*.*.176/29 dev p4p1  proto static  src *.*.*.182
172.27.7.0/24 dev p4p3  proto static  src 172.27.7.254

[root@eco ~]# ipsec status
Shunted Connections:
Bypass LAN *.*.*.176/29:  *.*.*.176/29 === *.*.*.176/29 PASS
Bypass LAN 172.27.7.0/24:  172.27.7.0/24 === 172.27.7.0/24 PASS
Security Associations (1 up, 0 connecting):
         vps[13]: ESTABLISHED 5 minutes ago, *.*.*.182[m.domain.cn]...*.*.188.145[vps.domain.cn]
         vps{37}:  INSTALLED, TUNNEL, reqid 21,* ESP SPIs*: c009bb30_i c463be21_o
         vps{37}:   172.27.7.0/24 === 10.76.15.254/32

firewall is accpept
Thanks for your help.

History

#1 Updated by Tobias Brunner 9 months ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Assignee deleted (Martin Willi)

My question is when ping intranet of b in a , can't capture packets in a,and received package in b;
when ping intranet of a in b,can't capture packets both a and b

Between what IPs did you try to ping?

Check traffic counters (either with ipsec statusall or ip -s xfrm state) to see if traffic is actually sent.

And i found it is "ESP in UDP SPIs " of b-c,does it affect?

UDP encapsulation is only required if there is a NAT between the two hosts.

#2 Updated by zhenxing huang 9 months ago

Tobias Brunner wrote:

My question is when ping intranet of b in a , can't capture packets in a,and received package in b;
when ping intranet of a in b,can't capture packets both a and b

Between what IPs did you try to ping?

I try to :
[root@eco ~]ping 10.76.15.254 of B on A.
[root@vps ~]ping 172.27.7.254 of A on B.

Check traffic counters (either with ipsec statusall or ip -s xfrm state) to see if traffic is actually sent.

[root@vps ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.1, Linux 2.6.32-642.el6.x86_64, x86_64):
  uptime: 4 hours, since Nov 15 03:40:56 2019
  malloc: sbrk 405504, mmap 0, used 390000, free 15504
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des rc2 sha2 sha3 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve socket-default bypass-lan farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic dhcp addrblock counters
Virtual IP pools (size/online/offline):
  192.168.10.16/28: 14/0/1
Listening IP addresses:
  B.B.188.145
  10.76.15.254
Connections:
         eco:  vps.domain.cn...A.A.27.182  IKEv2, dpddelay=30s
         eco:   local:  [vps.domain.cn] uses pre-shared key authentication
         eco:   remote: [m.domain.cn] uses pre-shared key authentication
         eco:   child:  10.76.15.254/32 === 172.27.7.0/24 TUNNEL, dpdaction=clear
        cert:  vps.domain.cn...%any  IKEv2, dpddelay=30s
        cert:   local:  [C=US, CN=vps.domain.cn] uses public key authentication
        cert:    cert:  "C=US, CN=vps.domain.cn" 
        cert:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
        cert:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Shunted Connections:
Bypass LAN 10.76.12.0/22:  10.76.12.0/22 === 10.76.12.0/22 PASS
Bypass LAN B.B.160.0/19:  B.B.160.0/19 === B.B.160.0/19 PASS
Bypass LAN 169.254.0.0/16:  169.254.0.0/16 === 169.254.0.0/16 PASS
Bypass LAN fe80::/64:  fe80::/64 === fe80::/64 PASS
Security Associations (1 up, 0 connecting):
         eco[6]: ESTABLISHED 93 minutes ago, B.B.188.145[vps.domain.cn]...A.A.27.182[m.domain.cn]
         eco[6]: IKEv2 SPIs: ae4e6902533e4507_i* 050a727121ac7ad5_r, pre-shared key reauthentication in 63 minutes
         eco[6]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
         eco{9}:  INSTALLED, TUNNEL, reqid 4, ESP SPIs: c713e8bc_i c0a99757_o
         eco{9}:  AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 36 minutes
         eco{9}:   10.76.15.254/32 === 172.27.7.0/24

[root@eco ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.3, Linux 2.6.32-754.6.3.el6.x86_64, x86_64):
  uptime: 10 hours, since Nov 15 10:51:14 2019
  malloc: sbrk 540672, mmap 0, used 382784, free 157888
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 11
  loaded plugins: charon aes des rc2 sha2 sha3 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve socket-default bypass-lan farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc tnc-tnccs dhcp whitelist addrblock counters
Virtual IP pools (size/online/offline):
  192.168.10.0/28: 14/0/2
  192.168.10.16/28: 14/0/0
Listening IP addresses:
  A.A.27.182
  172.27.7.254
  fdb2:cb99:f165:0:d6be:d9ff:fed1:16f3
Connections:
        ubnt:  m.domain.cn...%any  IKEv2, dpddelay=30s
        ubnt:   local:  [m.domain.cn] uses public key authentication
        ubnt:    cert:  "C=CN, CN=m.domain.cn" 
        ubnt:   remote: [C=CN, CN=ubnt@domain.cn] uses public key authentication
        ubnt:    cert:  "C=CN, CN=ubnt@domain.cn" 
        ubnt:   child:  172.27.7.0/24 === 192.168.1.96/27 TUNNEL, dpdaction=clear
         vps:  m.domain.cn...vps.domain.cn  IKEv2, dpddelay=30s
         vps:   local:  [m.domain.cn] uses pre-shared key authentication
         vps:    cert:  "C=CN, CN=m.domain.cn" 
         vps:   remote: [vps.domain.cn] uses pre-shared key authentication
         vps:   child:  172.27.7.0/24 === 10.76.15.254/32 TUNNEL, dpdaction=clear
        peap:  m.domain.cn...%any  IKEv2, dpddelay=30s
        peap:   local:  [m.domain.cn] uses public key authentication
        peap:    cert:  "C=CN, CN=m.domain.cn" 
        peap:   remote: uses EAP_RADIUS authentication with EAP identity '%any'
        peap:   child:  172.27.7.0/24 === dynamic TUNNEL, dpdaction=clear
        cert:  m.domain.cn...%any  IKEv2, dpddelay=30s
        cert:   local:  [m.domain.cn] uses public key authentication
        cert:    cert:  "C=CN, CN=m.domain.cn" 
        cert:   remote: uses public key authentication
        cert:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Shunted Connections:
Bypass LAN A.A.27.176/29:  A.A.27.176/29 === A.A.27.176/29 PASS
Bypass LAN 172.27.7.0/24:  172.27.7.0/24 === 172.27.7.0/24 PASS
Bypass LAN 169.254.0.0/16:  169.254.0.0/16 === 169.254.0.0/16 PASS
Bypass LAN fdb2:cb99:f165::/64:  fdb2:cb99:f165::/64 === fdb2:cb99:f165::/64 PASS
Bypass LAN fe80::/64:  fe80::/64 === fe80::/64 PASS
Security Associations (1 up, 0 connecting):
         vps[23]: ESTABLISHED 94 minutes ago, A.A.27.182[m.domain.cn]...B.B.188.145[vps.domain.cn]
         vps[23]: IKEv2 SPIs: ae4e6902533e4507_i 050a727121ac7ad5_r*, pre-shared key reauthentication in 71 minutes
         vps[23]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
         vps{64}:  INSTALLED, TUNNEL, reqid 34, ESP SPIs: c0a99757_i c713e8bc_o
         vps{64}:  AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 34 minutes
         vps{64}:   172.27.7.0/24 === 10.76.15.254/32

Thank for your reply.

#3 Updated by Tobias Brunner 9 months ago

[root@eco ~]ping 10.76.15.254 of B on A.
[root@vps ~]ping 172.27.7.254 of A on B.

OK, that should work based on the established SAs. Do you just get timeouts?

Check traffic counters (either with ipsec statusall or ip -s xfrm state) to see if traffic is actually sent.

Did you run ipsec statusall after the ping?

#4 Updated by zhenxing huang 9 months ago

Tobias Brunner wrote:

[root@eco ~]ping 10.76.15.254 of B on A.
[root@vps ~]ping 172.27.7.254 of A on B.

OK, that should work based on the established SAs. Do you just get timeouts?

Check traffic counters (either with ipsec statusall or ip -s xfrm state) to see if traffic is actually sent.

Did you run ipsec statusall after the ping?

This is information of run ipsec statusall and ip -s xfrm state and other after the ping.and i try to change auto=start to auto=route

[root@vps ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.1, Linux 2.6.32-642.el6.x86_64, x86_64):
  uptime: 13 hours, since Nov 19 07:05:41 2019
  malloc: sbrk 405504, mmap 0, used 389952, free 15552
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 9
  loaded plugins: charon aes des rc2 sha2 sha3 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs                          8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve socket-default bypass-l                          an farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-gener                          ic dhcp addrblock counters
Virtual IP pools (size/online/offline):
  192.168.10.16/28: 14/0/1
Listening IP addresses:
  B.B.188.145
  10.76.15.254
Connections:
         eco:  vps.domain.cn...A.A.27.182  IKEv2, dpddelay=30s
         eco:   local:  [vps.domain.cn] uses pre-shared key authentication
         eco:   remote: [m.domain.cn] uses pre-shared key authentication
         eco:   child:  10.76.15.254/32 === 172.27.7.0/24 TUNNEL, dpdaction=clear
        ubnt:  vps.domain.cn...%any  IKEv2, dpddelay=30s
        ubnt:   local:  [vps.domain.cn] uses pre-shared key authentication
        ubnt:   remote: uses pre-shared key authentication
        ubnt:   child:  10.76.15.254/32 === 192.168.1.96/27 TUNNEL, dpdaction=clear
        cert:  vps.domain.cn...%any  IKEv2, dpddelay=30s
        cert:   local:  [C=US, CN=vps.domain.cn] uses public key authentication
        cert:    cert:  "C=US, CN=vps.domain.cn" 
        cert:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
        cert:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Shunted Connections:
Bypass LAN 10.76.12.0/22:  10.76.12.0/22 === 10.76.12.0/22 PASS
Bypass LAN B.B.160.0/19:  B.B.160.0/19 === B.B.160.0/19 PASS
Bypass LAN 169.254.0.0/16:  169.254.0.0/16 === 169.254.0.0/16 PASS
Bypass LAN fe80::/64:  fe80::/64 === fe80::/64 PASS
Routed Connections:
         eco{1}:  ROUTED, TUNNEL, reqid 10
         eco{1}:   10.76.15.254/32 === 172.27.7.0/24
Security Associations (1 up, 0 connecting):
         eco[15]: ESTABLISHED 48 minutes ago, B.B.188.145[vps.domain.cn]...A.A.27.182[m.domain.cn]
         eco[15]: IKEv2 SPIs: b819cdacbefb762c_i a2459a1c5fae33ba_r*, pre-shared key reauthentication in 113 minutes
         eco[15]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
         eco{33}:  INSTALLED, TUNNEL, reqid 10, ESP SPIs: cb85996d_i c83f2f91_o
         eco{33}:  AES_CBC_128/HMAC_SHA2_256_128, 3368 bytes_i (47 pkts, 0s ago), 2928 bytes_o (26 pkts, 11s ago), rekeying in 43                           minutes
         eco{33}:   10.76.15.254/32 === 172.27.7.0/24
[root@vps ~]#



[root@vps ~]# ip -s xfrm state
src B.B.188.145 dst A.A.27.182
        proto esp spi 0xc83f2f91(3359584145) reqid 10(0x0000000a) mode tunnel
        replay-window 0 seq 0x00000000 flag 20 (0x00100000)
        auth hmac(sha256) 0xee1fb55aff8d8e664aeafde812d505402109912f9bce6e222ab64f95989e6c98 (256 bits)
        enc cbc(aes) 0x51caa98c8aec3a33ffc825efd1c2009c (128 bits)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 2982(sec), hard 3600(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          19952(bytes), 124(packets)
          add 2019-11-19 20:18:55 use 2019-11-19 20:22:23
        stats:
          replay-window 0 replay 0 failed 0
src A.A.27.182 dst B.B.188.145
        proto esp spi 0xcb85996d(3414530413) reqid 10(0x0000000a) mode tunnel
        replay-window 32 seq 0x00000000 flag 20 (0x00100000)
        auth hmac(sha256) 0xb6c77cb3d0c29829465aa92701eed53c212c4de93e5bd64a31cd2677e72f623e (256 bits)
        enc cbc(aes) 0xbea726bd05f49a2567da3f8fbc45ecce (128 bits)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 2955(sec), hard 3600(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          16432(bytes), 232(packets)
          add 2019-11-19 20:18:55 use 2019-11-19 20:22:23
        stats:
          replay-window 0 replay 0 failed 0
[root@vps ~]#



[root@vps ~]# iptables -nL
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp spt:53
ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 500,4500
ACCEPT     tcp  --  192.168.1.96/27      0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  172.27.7.0/24        0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  A.A.27.176/29      0.0.0.0/0           tcp dpt:22
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  172.27.7.0/24        10.76.15.254        policy match dir in pol ipsec reqid 10 proto 50
ACCEPT     all  --  10.76.15.254         172.27.7.0/24       policy match dir out pol ipsec reqid 10 proto 50
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[root@vps ~]# iptables -nL -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           policy match dir out pol ipsec
SNAT       all  --  192.168.10.0/27      0.0.0.0/0           to:B.B.188.145

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[root@vps ~]# iptables -nL -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
[root@vps ~]#

They are the same route for traceroute,the rule does not seem to take effect :

[root@vps ~]# ip route show table 220
172.27.7.0/24 via *.*.160.1 dev eth0  proto static  src 10.76.15.254

[root@vps ~]# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  * * *
 *2  lax1-11-1.it7.net (192.161.61.128)  1.094 ms  1.077 ms  1.060 ms*
 3  lax1-fatpipe-1.it7.net (69.12.70.234)  3.062 ms lax1-fatpipe-1.it7.net (69.12.70.232)  0.446 ms lax1-fatpipe-1.it7.net (69.12.70.234)  2.986 ms
 4  206.223.123.156 (206.223.123.156)  3.150 ms 69.12.69.2 (69.12.69.2)  0.540 ms  0.526 ms
 5  206.223.123.156 (206.223.123.156)  3.017 ms one.one.one.one (1.1.1.1)  0.654 ms 206.223.123.156 (206.223.123.156)  1.078 ms

[root@vps ~]# traceroute 172.27.7.254
traceroute to 172.27.7.254 (172.27.7.254), 30 hops max, 60 byte packets
 1  * * *
 *2  lax1-11-1.it7.net (192.161.61.128)  0.969 ms  0.968 ms  0.982 ms*
 3  * * *
 4  * * *

Thanks for your reply.

#5 Updated by Tobias Brunner 9 months ago

The counters show tunneled traffic in both directions (you could try to use -v with iptables to get hit counters for the rules to see if the ICMP rule is matched, or packets are actually dropped).

#6 Updated by zhenxing huang 9 months ago

Tobias Brunner wrote:

The counters show tunneled traffic in both directions (you could try to use -v with iptables to get hit counters for the rules to see if the ICMP rule is matched, or packets are actually dropped).

Moon(vps) and sun have the same rules.
However, moon can't ping sun.

[root@vps ~]# iptables -vnL
Chain INPUT (policy DROP 1033 packets, 333K bytes)
 pkts bytes target     prot opt in     out     source               destination
   14  1074 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:53
    0     0 ACCEPT     esp  --  eth0   *       0.0.0.0/0            0.0.0.0/0
  398 59467 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           multiport dports 500,4500
  319 25508 ACCEPT     tcp  --  *      *       192.168.1.96/27      0.0.0.0/0           tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       172.27.7.0/24        0.0.0.0/0           tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       A.A.27.176/29      0.0.0.0/0           tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth0   *       192.168.1.96/27      10.76.15.254        policy match dir in pol ipsec reqid 20 proto 50
    0     0 ACCEPT     all  --  *      eth0    10.76.15.254         192.168.1.96/27     policy match dir out pol ipsec reqid 20 proto 50
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 90 packets, 17848 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@vps ~]#
[root@vps ~]#
[root@vps ~]#
[root@vps ~]# iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 48 packets, 1972 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 16 packets, 1114 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           policy match dir out pol ipsec
    0     0 SNAT       all  --  *      *       10.76.12.0/22        0.0.0.0/0           to:B.B.188.145
    0     0 SNAT       all  --  *      *       192.168.10.0/27      0.0.0.0/0           to:B.B.188.145

Chain OUTPUT (policy ACCEPT 16 packets, 1114 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@vps ~]#

BTW.The following rules are required for sun ping moon of our instance.
but it is unnecessary in the example of net2net.

[root@vps ~]# iptables -vnL -t nat
Chain POSTROUTING (policy ACCEPT 16 packets, 1114 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           policy match dir out pol ipsec

Thanks for your reply.

#7 Updated by Tobias Brunner 9 months ago

Does it work if you change the default policy of the INPUT chain to ACCEPT?

BTW.The following rules are required for sun ping moon of our instance.
but it is unnecessary in the example of net2net.

It is required to avoid applying any NAT rules that might match. If they don't (e.g. because of the source IP filter), it's not necessary.

#8 Updated by zhenxing huang 9 months ago

Tobias Brunner wrote:

Does it work if you change the default policy of the INPUT chain to ACCEPT?

Still not working.

What do you think is the reason?

Thanks for your reply.

#9 Updated by Tobias Brunner 9 months ago

What do you think is the reason?

No idea. Try to follow the traffic through the network (using traffic/error counters and captures) to see where it gets dropped.

#10 Updated by zhenxing huang 9 months ago

Tobias Brunner wrote:

What do you think is the reason?

No idea. Try to follow the traffic through the network (using traffic/error counters and captures) to see where it gets dropped.

Reinstallation system solution.
Please close this.

Thanks for you reply .

Also available in: Atom PDF