ASA5505 and Sonicwall 4060 Confusion Frustration

Unanswered Question
Oct 29th, 2009
User Badges:

Ok here is the scenerio. I have a public IP address of x.x.x.x that is nat'd to 10.1.1.1. Traffic is sent from the ISP to 10.255.255.2 which is the WAN side of my Sonicwall. The Sonicwall then sends traffic of 10.1.1.0 to IP 172.31.0.2 which is the Outside Interface of my ASA. Traffic is then supposed to go to 10.1.1.1 which is a server on my DMZ interface of the ASA. Problem, I can see traffic coming in the ASA and being sent out to the 172.31.0.0 Interface, but it never gets to my server. As a test, I can put a laptop on the 172.31.0.0 network and use 172.31.0.2 as its gateway and I can get to the webserver. I'm thinking it has something to do with NAT on the ASA but not for sure. I have suppplied a simple diagram for what I have.



Attachment: 
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
snickered Thu, 10/29/2009 - 17:54
User Badges:

Sounds like the SonicWall gets the packet destined for 10.1.1.1 and doesn't know what to do with it. Add a static route on the SonicWall for the network 10.1.1.1 is on.

ronald.lawrimore Thu, 10/29/2009 - 18:36
User Badges:

sonicwall log shows that is is pushing traffic out of 172.31.0.1 and that is where is should be going.

snickered Thu, 10/29/2009 - 19:34
User Badges:

It really sounds like a routing problem. As soon as you plug in a laptop that has a default gateway of 172.31.0.2 you can hit your webserver. Check the routing tables on the SonicWall to be sure it knows how to get to 10.1.1.1. You said it reaches 172.31.0.1. So, what happens after that? Another good TS'ing step would be to setup a capture on the 172.31.0.2 interface to see if the traffic is actually getting that far. If it does then see if the traffic reaches the webserver with Wireshark/tcpdump on the webserver. If it does and you see the return traffic trying to go back maybe you don't have the routes setup properly on the ASA. Does the ASA know to get to the internet (default route)? Follow the packet.


Another thing it could be is internet traffic isn't allowed through the ASA. I know you said a laptop with the IP 172.31.0.1 can hit the webserver... maybe you have allowed the network with 172.31.0.1 and not internet traffic. Also, does the SonicWall allow the network with 10.1.1.1 to the internet? It's been a while since I've messed with a SonicWall but I think you'll have to add that as a "trusted source" (or something similar) to allow traffic to pass. Same with the way in. Does the SonicWall allow internet traffic to destination IP 10.1.1.1?


Too many variables. Sell the SonicWall on eBay. ;)


snickered Fri, 10/30/2009 - 22:16
User Badges:

That's a good drawing. Did you happen to get a capture on the 172.31.0.2 interface or webserver? We need to make sure the packet is getting to the ASA or webserver. If it is then we can focus on the ASA.


Also, I don't really understand how your SonicWall knows traffic from 216.x.x.1 is NAT'ed. By the time the SonicWall gets the packet it should already be NAT'ed by the Adtran so, the SonicWall would see a packet that has a source address of the person on the internet making the request and a destination address of 192.168.0.2. It shouldn't see the destination address of 216.x.x.1 if the Adtran is doing the translation. Here's how it would work:


Let's say someone is on the internet with IP address 5.5.5.5. They make a request to your webserver at 216.x.x.1:80. So, the packet would look like:


src: 5.5.5.5:5464 dst: 216.x.x.1:80

(**note, I made up the source IP and port)


Once the Adtran sees the packet it will change the dst address to 192.168.0.2:80. So, the packet will look like the following when the X1 interface on the SonicWall gets it:


src: 5.5.5.5:5464 dst: 192.168.0.2:80


Now, assuming the SonicWall has a route to the 192.168.0.2 network and is allowed to send packets there it will route the packet to E0/7. When E0/7 gets the packet it will look like:


src: 5.5.5.5:5464 dst: 192.168.0.2:80


Once E0/7 gets the packet it will see 192.168.0.2 is on a connected interface and send the packet out E0/6 (assuming it is allowed to).


Let's get a capture on the E0/7 interface as well as the webserver and we'll be able to see what's going on a little better.



ronald.lawrimore Tue, 11/03/2009 - 09:38
User Badges:

Ok, I've got my NAT working from the ISP. The Sonicwall is forwarding traffic to 192.16.0.2 like is should. On the ASA I am getting this each time I try to browse to my webserver.


A duplicate TCP SYN was received during the three-way-handshake that has a different initial sequence number than the SYN that opened the embryonic connection

ronald.lawrimore Wed, 11/04/2009 - 04:39
User Badges:

It looks like it does, but I don't get my webpage. I think this message is because it is a multihomed server. Is there a way to bypass this message for this one server?

ronald.lawrimore Wed, 11/04/2009 - 05:41
User Badges:

Deny TCP (no connection) from 172.16.0.2/80 to 216.48.9.65/24496 flags SYN ACK on interface inside


snickered Wed, 11/04/2009 - 07:37
User Badges:

Setup a sniffer on your webserver and see if the packet gets to the webserver. I don't know what to do about the error you're getting. To me the error looks like the SYN/ACK packet isn't getting back to the client therefore the client is retransmitting the SYN. Maybe someone else can clarify. At this point we have no idea where it's failing. Setup a sniffer on the webserver. We need to follow the packet to see what's going on.

Actions

This Discussion