1

I have a client request web service on a server behide NAT. My client IP is 10.54.10.193 NAT address: 10.54.28.183 Server address: 62.209.39.203

When client request web service on server we have TCP previous segment not captured as image below: client side capture

But at server side everything seems to be normal as image below: server side capture

When I run debug ip nat detailed I got this error:

*Aug 21 20:52:52.256: NAT*: Can't create new inside entry - forced_punt_flags: 0 
*Aug 21 20:52:52.256: NAT*: i: tcp (62.209.39.203, 8083) -> (10.54.10.193, 64652) [30259] 
*Aug 21 20:52:52.256: NAT*: s=62.209.39.203->10.54.28.183, d=10.54.10.193 [30259]

My config as follow:

Current configuration : 2873 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname VDC-CTIN-3725
!
boot-start-marker
boot system flash:c3725-advsecurityk9-mz.124-15.T14.bin
boot-end-marker
!
no aaa new-model
no network-clock-participate slot 1
ip cef
!
!
!
!
!
multilink bundle-name authenticated

interface Loopback0
 ip address 10.54.1.1 255.255.255.255
!
interface FastEthernet0/0
 description LAN-IDC
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 123.30.169.46 255.255.255.192
 ip nat inside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 crypto map Mobifone-to-Nuance
!
interface FastEthernet1/0
 description MobiFone Metronet
 ip address 10.54.28.183 255.255.255.224
 ip nat outside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet1/1
 description VinaPhone
 no ip address
 shutdown
 duplex auto
 speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
ip route 10.54.10.0 255.255.255.0 FastEthernet1/0 10.54.28.161 name VMS-PS
ip route 10.54.30.0 255.255.255.0 FastEthernet1/0 10.54.28.161 name VMS-VG
!
!
no ip http server
no ip http secure-server
ip nat source static tcp 192.168.1.2 3389 interface FastEthernet0/1 3389
ip nat inside source list 100 interface FastEthernet1/0 overload
ip nat inside source static tcp 62.209.39.197 8080 10.54.28.183 8080 extendable
ip nat inside source static tcp 62.209.39.203 8083 10.54.28.183 8083 extendable
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 10.54.0.0 0.0.255.255
access-list 100 permit ip 62.209.39.192 0.0.0.15 10.54.0.0 0.0.255.255
access-list 100 permit icmp 62.209.39.192 0.0.0.15 10.54.0.0 0.0.255.255
access-list 101 permit ip 10.54.0.0 0.0.255.255 62.209.39.192 0.0.0.15
access-list 101 permit ip 192.168.1.0 0.0.0.255 62.209.39.192 0.0.0.15
access-list 101 permit icmp 192.168.1.0 0.0.0.255 62.209.39.192 0.0.0.15

Is there anything wrong with my NAT config? Please help me.

moodym
  • 11
  • 4
  • All we can see is that one packet was lost. That happens sometimes. Unless this happens repeatedly, I wouldn't worry about it. There appears to be nothing unusual about that packet. It could have been dropped by the NAT or any other router along the path. – kasperd Aug 18 '15 at 06:54
  • Hi kasperd, It happens repeatedly with the same packet! – moodym Aug 18 '15 at 08:35
  • More information will be needed. If you upload a pcap file it might contain the information needed to identify the problem. – kasperd Aug 18 '15 at 08:44
  • Hi kasperd, This is the pcap file for serverside: https://copy.com/XEdNU21mGGzExwxm and client side: https://copy.com/h1t3IuUswoRNyntN – moodym Aug 18 '15 at 09:19
  • Is there a specific request in the capture which is of interest? – kasperd Aug 18 '15 at 09:35
  • Hi kasperd, Line 21 tcp.stream eq 4 client side – moodym Aug 18 '15 at 09:37
  • That request is before the start of the server side capture. – kasperd Aug 18 '15 at 09:43
  • Sorry, we should use line 151 tcp.stream eq 16 – moodym Aug 18 '15 at 10:18
  • The clocks on the two ends of the connection are off by 7 seconds. Nothing obviously wrong with the packets. A wild guess would be that the NAT gets confused by the client sending a FIN packet before the server has send the reply. Maybe due to a bug in the NAT it will not allow anymore packets from server to client unless the packet from server to client is also a FIN packet. – kasperd Aug 18 '15 at 10:49
  • Hi kasperd, Thanks for your help. As I understand the problem might be the delay of server response. Actually, Our network model is quite complicated. Our client is put in a telecom carrier server center, they do not accept our client connect to internet directly, so we have to put a router outside carrier center and make it as a DMZ. From DMZ we have a VPN site to site with the server that hosting the service on internet configured on router, because carrier not allow route to the internet server we also configure NAT on this router. Should we remove the VPN for faster access? – moodym Aug 18 '15 at 11:14
  • Hi @kasperd, I found the error on router I run command debug ip nat detailed and get `*Aug 21 20:52:52.256: NAT*: Can't create new inside entry - forced_punt_flags: 0 *Aug 21 20:52:52.256: NAT*: i: tcp (62.209.39.203, 8083) -> (10.54.10.193, 64652) [30259] *Aug 21 20:52:52.256: NAT*: s=62.209.39.203->10.54.28.183, d=10.54.10.193 [30259]` How can I get over it? – moodym Aug 22 '15 at 10:02
  • You are much more likely to get an answer, if you update the question with relevant information rather than juts adding comments. – kasperd Aug 22 '15 at 19:32
  • Good, then let's hope somebody with more knowledge of that platform will see the question. – kasperd Aug 23 '15 at 08:22

0 Answers0