03-17-2010 02:24 PM
This sounds really spooky.
I cannot understand that your pc dan do a dns lookup, but cant' resolve the ip-address the fully qualified domain name when you type it into your browser??
What happens if you try to type the following from the comman line on your laptop:
telnet www.google.com 80
Your command line should go blank to show you are connected. (You can break that with CTRL + ¨ and then type quit)
03-18-2010 08:41 AM
(this isnt copy paste, its just typed out so... )
126.96.36.199 XX.XX.XX.XX XX.XX.XX.XX
telnet 188.8.131.52 80
I've seen others who have had this issue so its not a real oddity, but i havent found a solution. Would anything block dns from resolving to the application layer? Oh, and i dont have any proxies setup in my browsers. Also tried multiple browsers.
03-18-2010 11:14 AM
1. Which ScreenOS version do you run.
2. As i understood you have configured wireless in the DMZ-zone is that an external AP or is it integrated with the SSG-20.
3. What is the model of your laptop and which wireless adapter has it got.
4. Do you experience the same problems both on wireless and wired connection.
5. Have you tried doing the debugging part i mentioned in an earlier post.
6 If your firewall is configured with dns, hostname and domain-name you should try the following.
ping www.google.com from ethernet0/1
03-18-2010 11:44 AM
1. 6.1.0r4.0 (Firewall+VPN)
2. It is an external AP which i pulled from our existing wireless network. (Netgear)
3. I have a Dell Precision m2400 (Intel wifi link 5300 AGN) (I have attempted to get to google from multiple laptops with the same outcome)
4. The DMZ eth0/1 port goes directly into the AP. I do not have access to a wired port. I could remove the wireless though.
5. The last time i did the debugging part, it seemed like the same spam message over and over again. I will run it and post what i get.
6. My Firewall is configured with DNS, not sure i follow you with the domain or host name. My SSG20 does not have a domain name.
03-18-2010 12:02 PM
Removing the AP from the picture didnt do anything. STill the same problem. Below is the debug, this continues pretty much on forever:
Processing packet through normal path.
Packed passed sanity check
self:10.2.2.1/23 _> 10.2.2.105/1153,6<root>
existing session found. sess token 5
flow got session.
flow session id 7473
skip ttl adjust for packet from self.
post addr xlation 10.2.2.1->10.2.2.105.
flow_send_vector_, vid=0, is layer_2_if=0
packet send out to 0019b956515c through ethernet0/1
****8548727.0: <DMZ/ethernet0/1> packet receieved *******
ipid = 16337<3fd1>, @033c1fd0
packet passed sanity check
existing session found. sess token 13
flow got session flow session id 74.73
post addr xlation 10.2.2.105->10.2.2.1.
packet is for self, copy packet to self
copy packet to us
****** 8548727.0 >self/self> packet received  *************
ipid = asoihgapsidew6y9-12ht-
This continues for pages and pages and pages... i think it eventually gets to my wan address. my computer died before i could get to it though.
hopefully this gives you an idea.
You said in your second post to configure a DIP. Would you still like me to do this?
03-19-2010 02:43 AM
The debug yoy have pasted into the post doesn't' show anything as it is not traffic going through firewall.
As to nat you dont' have to configure DIP as long as you use the nat src in your policy it will translate the source-ip to that of the external interface.
Right now I have the problem that I cannot see the configuration and see what goes wrong.
What I would recommend is that you open a Case at JTAC. What they wil probably do is ask for the output from get tech or get you to connect to a secure metting where the can see the output from your Terminal emulation, so that they can see what is wrong.
I am convinced that as soon as you have a JTAC engineer looking at your configuration he will quickly see where the problem is.
03-19-2010 07:41 AM
So i did the dishonorable thing and did a work around. There is something with Juniper routers and DMZ's that i do not know about which is giving me the above error. Anyways...
I bound eth0/4 to bgroup1 and setup a new subnet with in it on the trust network. I then created a new policy to restrict the subnet of bgroup1 from bgroup0. Got it up and running in 1.5 minutes using the exact same settings as those used in the DMZ minus the nat-src setting.
I would still be interested in knowing what extra step is needed for the DMZ to work correctly.