Yes, I was missing something. I wasn't keeping track of my packets coming from the nat boxes (PREROUTING). Now I can see for how long it will keep track of that connection, therefore have more hosts making the connection to the remote server. 222.222.222.222 -> the remote server' ip address 555.555.555.555 -> my public ip address ------ before connection tracking unknown 47 542 src=222.222.222.222 dst=555.555.555.555 packets=15 bytes=919 [UNREPLIED] src=192.168.10.70 dst=222.222.222.222 packets=0 bytes=0 mark=0 use=1 ------ after connection tracking unknown 47 520 src=192.168.10.70 dst=222.222.222.222 packets=98 bytes=10005 src=222.222.222.222 dst=555.555.555.555 packets=168 bytes=13368 mark=0 use=1 The third argument is the 'timer', which is decreasing from '600' (seconds). So I figure that this is the compiled timeout for the 'gre' (47) protocol. So the problem should be gone... but its not. Debuging.... 192.168.10.116 had the connection, already closed, so the connection tracking is still there (/proc/net/ip_conntrack) but useless (right ?) 192.168.10.70 is trying to connect 222.222.222.222 is the remote address (.....) 03:25:29.162994 IP 192.168.10.70.2054 > 222.222.222.222.1723: P 325:349(24) ack 189 win 65347: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(0) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff) 03:25:29.166692 IP 192.168.10.70 > 222.222.222.222: GREv1, call 0, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23 03:25:29.177072 IP 222.222.222.222 > 192.168.10.116: GREv1, call 61290, ack 4294967295, no-payload, length 12 03:25:29.223171 IP 222.222.222.222.1723 > 192.168.10.70.2054: . ack 349 win 5840 03:25:29.351156 IP 222.222.222.222 > 192.168.10.116: GREv1, call 61290, seq 1, length 41: LCP, Conf-Request (0x01), id 1, length 27 03:25:31.166831 IP 192.168.10.70 > 222.222.222.222: GREv1, call 0, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23 (....) The conntrack entry for the old connection is getting hits when the new connection is made, and there's no new conntrack entry for the new attempt. rtrp0:/proc/net # egrep "222.222.222.222" ip_conntrack unknown 47 598 src=192.168.10.116 dst=222.222.222.222 packets=44 bytes=5291 src=222.222.222.222 dst=555.555.555.555 packets=121 bytes=6883 mark=0 use=1 rtrp0:/proc/net # And thats it. Where's the new connection from 192.168.10.70 ? -- Thiago Lucas thiago@xxxxxxxxxxxxx POWERSolutions Inf. Ltda. +55 (48) 3234-5500 thiago@xxxxxxxxxxxxx Enviado Por: netfilter-bounces@xxxxxxxxxxxxxxxxxxx 11/08/2006 14:07 Para netfilter@xxxxxxxxxxxxxxxxxxx cc Assunto issue with 'gre' over nat Hello, I have made some research in the maillist history, but had no luck. The scenario: nated boxes -> iptables gateway -> internet -> vpn server (runs pptp, and has iptables also) Note:1) allways trying one connection at time, 2) connection tracking module is loaded I can establish vpn connections (and acctually make use of it) with the remote vpn server many times, when the requests are originated from the same box (behind nat); if another computer behind this same nat tries to connect this vpn server, the tunnel doesn't come up. So we have: computer1 -> vpn server (successful connect) computer1 -> vpn server (successful disconnect) computer1 -> vpn server (successful connect) computer1 -> vpn server (successful disconnect) computer2 -> vpn server (successful pptp connection, but stopping when the tunnel should came up) Tcpdump'ing the internal interface of the iptables gateway, I could see why. When the 'computer2' tries to make the connection, the 'gre' packets are being forwarded to the wrong box, this scenario 'computer1'. 192.168.10.116 is the 'computer1', that has already finished his connection with the remote vpn server. 192.168.10.107 is the 'computer2', trying to establish connection 222..222.222.222 is the remote host, just wrote that way to make easier to read. Here´s the unsuccessful connection debug: ## #### looks normal from here until..... ## 22:17:25.728082 IP (tos 0x0, ttl 128, id 12557, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.10.179.2161 > 222.222.222.222.1723: S, cksum 0xd82a (correct), 4215463976:4215463976(0) win 65535 <mss 1460,nop,nop,sackOK> 22:17:25.844511 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto: TCP (6), length: 44) 222.222.222.222.1723 > 192.168.10.179.2161: S, cksum 0x7930 (correct), 1610087720:1610087720(0) ack 4215463977 win 5840 <mss 1460> 22:17:25.844724 IP (tos 0x0, ttl 128, id 12558, offset 0, flags [DF], proto: TCP (6), length: 196) 192.168.10.179.2161 > 222.222.222.222.1723: P 1:157(156) ack 1 win 65535: pptp Length=156 CTRL-MSG Magic-Cookie=1a2b3c4d CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) [|pptp] 22:17:25.966502 IP (tos 0x0, ttl 62, id 55217, offset 0, flags [DF], proto: TCP (6), length: 40) 222.222.222.222.1723 > 192.168.10.179.2161: ., cksum 0x9051 (correct), 1:1(0) ack 157 win 5840 22:17:25.971002 IP (tos 0x0, ttl 62, id 55219, offset 0, flags [DF], proto: TCP (6), length: 196) 222.222.222.222.1723 > 192.168.10.179.2161: P 1:157(156) ack 157 win 5840: pptp Length=156 CTRL-MSG Magic-Cookie=1a2b3c4d CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1:Successful channel establishment) ERR_CODE(0:None) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) [|pptp] 22:17:25.971218 IP (tos 0x0, ttl 128, id 12559, offset 0, flags [DF], proto: TCP (6), length: 208) 192.168.10.179.2161 > 222.222.222.222.1723: P 157:325(168) ack 157 win 65379: pptp Length=168 CTRL-MSG Magic-Cookie=1a2b3c4d CTRL_MSGTYPE=OCRQ CALL_ID(256) CALL_SER_NUM(48271) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) [|pptp] 22:17:26.096576 IP (tos 0x0, ttl 62, id 55221, offset 0, flags [DF], proto: TCP (6), length: 72) 222.222.222.222.1723 > 192.168.10.179.2161: P, cksum 0x4f2e (correct), 157:189(32) ack 325 win 5840: pptp Length=32 CTRL-MSG Magic-Cookie=1a2b3c4d CTRL_MSGTYPE=OCRP CALL_ID(0) PEER_CALL_ID(256) RESULT_CODE(1:Connected) ERR_CODE(0:None) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(32) PROC_DELAY(0) PHY_CHAN_ID(0) 22:17:26.100325 IP (tos 0x0, ttl 128, id 12560, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.10.179.2161 > 222.222.222.222.1723: P, cksum 0x4fb9 (correct), 325:349(24) ack 189 win 65347: pptp Length=24 CTRL-MSG Magic-Cookie=1a2b3c4d CTRL_MSGTYPE=SLI PEER_CALL_ID(0) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff) ## #### ...here, where the gre requests from 192.168.10.179 are returning wrongly to 192.168.10.116, that has nothing to do with this connection ## 22:17:26.102743 IP (tos 0x0, ttl 128, id 12561, offset 0, flags [none], proto: GRE (47), length: 57) 192.168.10.179 > 222.222.222.222: GREv1, Flags [key present, sequence# present], call 0, seq 0, length 37 22:17:26.122530 IP (tos 0x0, ttl 62, id 11033, offset 0, flags [DF], proto: GRE (47), length: 65) 222.222.222.222 > 192.168.10.116: GREv1, Flags [key present, sequence# present, ack present], call 256, seq 1, ack 4294967295, length 45 22:17:26.276681 IP (tos 0x0, ttl 62, id 55223, offset 0, flags [DF], proto: TCP (6), length: 40) 222.222.222.222.1723 > 192.168.10.179.2161: ., cksum 0x8ed5 (correct), 189:189(0) ack 349 win 5840 22:17:28.103080 IP (tos 0x0, ttl 128, id 12564, offset 0, flags [none], proto: GRE (47), length: 57) 192.168.10.179 > 222.222.222.222: GREv1, Flags [key present, sequence# present], call 0, seq 1, length 37 22:17:28.122612 IP (tos 0x0, ttl 62, id 11034, offset 0, flags [DF], proto: GRE (47), length: 61) 222.222.222.222 > 192.168.10.116: GREv1, Flags [key present, sequence# present], call 256, seq 2, length 41 22:17:30.123688 IP (tos 0x0, ttl 62, id 11035, offset 0, flags [DF], proto: GRE (47), length: 61) 222.222.222.222 > 192.168.10.116: GREv1, Flags [key present, sequence# present], call 256, seq 3, length 41 22:17:31.103318 IP (tos 0x0, ttl 128, id 12565, offset 0, flags [none], proto: GRE (47), length: 57) 192.168.10.179 > 222.222.222.222: GREv1, Flags [key present, sequence# present], call 0, seq 2, length 37## ##... and so on until 'disconnect'. In my '/proc/net/ip_conntrack' file, there's still the register for the previously disconnected connection. ps.: 555.555.555.555 is my gateway public address ... unknown 47 550 src=192.168.10.116 dst=222.222.222.222 packets=1047 bytes=154888 src=222.222.222.222 dst=555.555.555.555 packets=1984 bytes=990206 mark=0 use=1 ... Any known issues about it ? Or did I missed something ? Maybe connectiong tracking timeout is too long ? I don't believe or have knowledge of something at the remote that could generate this kind of situation, as all that the remote host knows about me is my public ip address and the mac address of my gateway's internal interface... Thanks in advance. -- Thiago Lucas thiago@xxxxxxxxxxxxx POWERSolutions Inf. Ltda.
