azpete
asked on
Two Firewalls in series and Packet Capture
Two Firewalls in series, SonicWall on WAN side and ASUS behind the SonicWall.
I have the above setup where the Sonicwall provides a LAN address of 192.168.168.XXX to a ASUS firewall provides my actual devices (PCs etc) with 10.0.0.XXX LAN
All works just the way I need and want it to, please do not offer any config changes
.
QUESTION Since the 10.xxxxx LAN is essentially a Translated 192.xxxxx address CAN anyone tell me how to configure my SonicWall Packet Capture screen to see the translated PC IPs ?
Note: I only see 192.168.x.x in a Global Packet Capture and suspect that it may be that the asus knows that 10.0.0.5 is translating to 192.168.168.65 but I am not yet convinced.
I have the above setup where the Sonicwall provides a LAN address of 192.168.168.XXX to a ASUS firewall provides my actual devices (PCs etc) with 10.0.0.XXX LAN
All works just the way I need and want it to, please do not offer any config changes
.
QUESTION Since the 10.xxxxx LAN is essentially a Translated 192.xxxxx address CAN anyone tell me how to configure my SonicWall Packet Capture screen to see the translated PC IPs ?
Note: I only see 192.168.x.x in a Global Packet Capture and suspect that it may be that the asus knows that 10.0.0.5 is translating to 192.168.168.65 but I am not yet convinced.
Hi azpete,
I really think you should change this configuration immediately! LOL
You can packet capture through NAT or double NAT in your scenario so there is nothing special...use the Packet Capture within the SonicWALL as you normally would...if you want to filter on Source IP, Destination IP, etc. do so as you normally would.
Does that make sense? Let me know if you have any other questions!
I really think you should change this configuration immediately! LOL
You can packet capture through NAT or double NAT in your scenario so there is nothing special...use the Packet Capture within the SonicWALL as you normally would...if you want to filter on Source IP, Destination IP, etc. do so as you normally would.
Note: I only see 192.168.x.x in a Global Packet Capture and suspect that it may be that the asus knows that 10.0.0.5 is translating to 192.168.168.65 but I am not yet convinced.Yes, you handle it in the same manner if there were only one firewall...you wouldn't even think about the NAT translations but rather the Source IP/s and/or port/s, and the Destination IP/s and/or port/s, etc. All the devices downstream will go through the SonicWALL regardless!
Does that make sense? Let me know if you have any other questions!
Maybe I misunderstood your question....
Are you asking if you can see the 10.x.y.z addresses from the SonicWall when you do your packet captures?
Are you asking if you can see the 10.x.y.z addresses from the SonicWall when you do your packet captures?
ASKER
Joseph, yes, I AM asking if I can see the 10.x.y.z addresses from the SonicWall when I do a packet capture.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
When I do a Capture EVERYTHING on the SonicWall all I see is ONE "Lan" IP on the sonicwall ( which is the "wan" address of the ASUS)
this actually makes perfect sense . Then I thought - hey I know the MAC addresses of everything on the LAN. BUT the Sonicwall Packet capture does not appear to have a MAC field to capture
this actually makes perfect sense . Then I thought - hey I know the MAC addresses of everything on the LAN. BUT the Sonicwall Packet capture does not appear to have a MAC field to capture
Yeah.... MAC addresses are L2, so they're not passed between network segments
I fully answered the question and follow ups.
The SW firewall never sees those internal addresses - that's kind of the whole point of NAT and firewalls. So, it has no way of doing a translation.
The only box that will be able to capture packets like that is the ASUS.
To clarify - The ASUS box is the one that does the translations from 10.x.y.z to 192.168.168.z. Therefore, it maintains the translation tables. The SW has no way of reading those tables, so it has no way of knowing which internal address is being represented by the DMZ address.