SRX

We have Juniper SRX100 to Cisco 2811 route based VPN implementation over ADSL. On SRX side - ADSL modem in bridge mode, on Cisco side - ADSL modem in routed mode. And we have issue with one application, that can't  contact to the server for data transmit. Early, we have same issue with GRE-over-IPSEC on Cisco-to-Cisco implementation, and we resolve it with setting MTU on tunnel interface to 1400 and setting tcp-mss on internal interfaces of routers to 1360.

Cisco 2811 config:

crypto isakmp policy 5
 encr aes 256
 authentication pre-share
 group 5

crypto isakmp key SECRET_KEY address 10.10.10.2

crypto ipsec transform-set VTI esp-aes 256 esp-sha-hmac 
 mode transport

crypto ipsec profile VTI
 set transform-set VTI 
 set pfs group5

interface Tunnel19
 bandwidth 128
 ip address 172.16.1.1 255.255.255.252
 ip mtu 1400
 ip nat inside
 ip virtual-reassembly
 tunnel source FastEthernet0/1.122
 tunnel destination 10.10.10.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

interface FastEthernet0/1.122
 encapsulation dot1Q 122
 ip address 192.168.102.244 255.255.255.0
 ip mtu 1492

 SRX100 config:

fe-0/0/0 {
    unit 0 {
        encapsulation ppp-over-ether;
    }

pp0 {
    unit 0 {
        ppp-options {
            pap {
                local-name "user";
                local-password "$9$ddaF#5Q/CtuOBRhu0WLXNbwTzFntu"; ## SECRET-DATA
                passive;
            }
        }
        pppoe-options {
            underlying-interface fe-0/0/0.0;
            idle-timeout 0;
            auto-reconnect 10;
            client;
        }
        family inet {
            mtu 1492;
            negotiate-address;
        }
    }
}

st0 {
    unit 0 {
        family inet {
            mtu 1400;
            address 172.16.1.2/30;
        }
    }
}


proposal MAIN_IKE_PROPOSAL {
    description "IKE CONFIG FOR PUZZLE";
    authentication-method pre-shared-keys;
    dh-group group5;
    authentication-algorithm sha1;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 86400;
}
policy MAIN_IKE_POLICY {
    description "IKE POLICY FOR PUZZLE";
    proposals MAIN_IKE_PROPOSAL;
    pre-shared-key ascii-text "$9$4SoZDf5F36(*&^jhbdasn132AUjqfznpulKMLNb2gJji.4afTznCAylK8LN"; ## SECRET-DATA
}
gateway MAIN_IKE_GATE {
    ike-policy MAIN_IKE_POLICY;
    address 192.168.102.244;
    external-interface pp0.0;
}


proposal MAIN_IPSEC_PROPOSAL {
    description "IPSEC PROPOSAL FOR PUZZLE";
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 28800;
    lifetime-kilobytes 4608000;
}
policy MAIN_IPSEC_POLICY {
    description "IPSEC POLICY FOR PUZZLE";
    perfect-forward-secrecy {
        keys group5;
    }
    proposals MAIN_IPSEC_PROPOSAL;
}
vpn CO_VPN {
    bind-interface st0.0;
    ike {
        gateway MAIN_IKE_GATE;
        ipsec-policy MAIN_IPSEC_POLICY;
    }
    establish-tunnels immediately;
}


tcp-mss {
    all-tcp {
        mss 1360;
    }
    ipsec-vpn {
        mss 1360;
    }
}

If we replace SRX100 with Cisco 857 - all works fine.

Cisco 857 config:

crypto isakmp policy 5
 encr aes 256
 authentication pre-share
 group 5  
crypto isakmp key SECRET_KEY address 192.168.102.244
crypto isakmp invalid-spi-recovery
!
crypto ipsec security-association lifetime seconds 28800
!
crypto ipsec transform-set VTI esp-aes 256 esp-sha-hmac 
 mode transport
!
crypto ipsec profile VTI
 set transform-set VTI 
 set pfs group5

interface Tunnel0
 bandwidth 128
 ip address 172.16.1.2 255.255.255.252
 ip mtu 1400
 tunnel source Dialer0
 tunnel destination 192.168.102.244
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI


interface Dialer0
 description ISP PPPoE
 bandwidth 128
 ip address negotiated
 ip mtu 1492
 encapsulation ppp
 dialer pool 1
 ppp authentication pap callin
 ppp pap sent-username user password 0 1234567890

Sorry... It's my typo, MTU on st0.0 is 1400. I corrected its value in first post.

tcpdump from server where client connected (test connection to the server):

10:49:27.793981 IP (tos 0x0, ttl 126, id 172, offset 0, flags [none], proto 6, length: 44) 172.16.90.2.1043 > ora9i-test.domain.com.1521: S [tcp sum ok] 2481740521:2481740521(0) win 32120 <mss 1360>
10:49:27.794061 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 6, length: 44) ora9i-test.domain.com.1521 > 172.16.90.2.1043: S [tcp sum ok] 3087693221:3087693221(0) ack 2481740522 win 5840 <mss 1460>
10:49:27.797212 IP (tos 0x0, ttl 126, id 174, offset 0, flags [none], proto 6, length: 40) 172.16.90.2.1043 > ora9i-test.domain.com.1521: . [tcp sum ok] 1:1(0) ack 1 win 32120
10:49:27.797406 IP (tos 0x0, ttl 126, id 176, offset 0, flags [none], proto 6, length: 180) 172.16.90.2.1043 > ora9i-test.domain.com.1521: P 1:141(140) ack 1 win 32120
10:49:27.797420 IP (tos 0x0, ttl  64, id 35035, offset 0, flags [DF], proto 6, length: 40) ora9i-test.domain.com.1521 > 172.16.90.2.1043: . [tcp sum ok] 1:1(0) ack 141 win 5840
10:49:27.833062 IP (tos 0x0, ttl  64, id 35037, offset 0, flags [DF], proto 6, length: 48) ora9i-test.domain.com.1521 > 172.16.90.2.1043: P [bad tcp cksum b39b (->b35b)!] 1:9(8) ack 141 win 5840
10:49:27.835151 IP (tos 0x0, ttl 126, id 177, offset 0, flags [none], proto 6, length: 40) 172.16.90.2.1043 > ora9i-test.domain.com.1521: . [tcp sum ok] 141:141(0) ack 9 win 32112

I try to listen traffic on client side with wireshark, and i find, that this

10:49:27.833062 IP (tos 0x0, ttl  64, id 35037, offset 0, flags [DF], proto 6, length: 48) ora9i-test.domain.com.1521 > 172.16.90.2.1043: P [bad tcp cksum b39b (->b35b)!] 1:9(8) ack 141 win 5840

packet is not returned to client. May be it droped on SRX? I have default screen options ou untrust interface:

ids-option untrust-screen {
    icmp {
        ping-death;
    }
    ip {
        source-route-option;
        tear-drop;
    }
    tcp {
        syn-flood {
            alarm-threshold 1024;
            attack-threshold 200;
            source-threshold 1024;
            destination-threshold 2048;
            timeout 20;
        }
        land;
    }
}

After hours of wireshark and tcpdump analysis and tones of searches in google I find solution in this article:

http://packetpushers.net/sqlnet-a-k-a-oracle-tns-and-firewalls/

(Juniper KB link - http://kb.juniper.net/InfoCenter/index?page=content&id=KB17852&actp=RSS)

Solution - disable SQL ALG on SRX.

I changed the subject of the topic that it displays the true nature of the problem