This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Routing/access problem that just showed up with 7.401

I have a 320 that I just upgraded to 7.401 (from .3 something) and I have a problem getting people from inside our network to be able to see our own website.

We have a unique IP addy for the website that resolves to 66.213.240.155. I have the firewall automatically route via DNAT from any http destination 66.213.240.155 to our internal dmz located webserver at 10.2.1.80.

From the internal network (10.2.2.X) I can nslookup and resolve correctly and I can ping it. I've viewed the packet rules using live log and nothing is getting fired when trying to view the website. I also get nothing by trying to directly connect to http://66.213.240.155. I can't telnet into that address at port 80 either.

I've got three network plugs, internal (10.2.2.X), dmz (10.2.1.X) and internet with all of our public IP addy's connect directly to our T1 CSU/DSU.

This just stopped working with our upgrade to 7.4.

I'm a bit at a loss as to why this suddenly stopped working and how I can try to figure out what is going on.

This thread was automatically locked due to age.

0 BarryG over 16 years ago

Is 66.213.240.155 your primary firewall external interface, or an "additional" address, or ?

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 BAlfson over 16 years ago in reply to BarryG

Try opening the DNAT definition and resaving it - another user reported that that solved a similar problem. You might try the same with your masq rule. Good question, Barry.

Cheers - Bob
Cancel
Vote Up 0 Vote Down

Cancel
0 predatorsw over 16 years ago in reply to BAlfson

It's an "additional," primary is .154

A re-save of dnat and masq didn't seem to improve things. It's like dnat isn't working for the 10.2.2.X internal addy's. I'll add a specific dnat from internal to the webserver and see if that helps.
Cancel
Vote Up 0 Vote Down

Cancel
0 predatorsw over 16 years ago in reply to predatorsw

I put in a specific dnat rule internal network 10.2.2.0/24, http to 66.213.240.155 to go to 10.2.1.80 and it still doesn't like it. Sounds like we may have an official bug on our hands? It seems a little strange as the dnat rule from our external ip addy to the ftpwebserver appears to work.
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 16 years ago in reply to predatorsw

If you have support, you should probably open a case.

You could run tcpdump on both the ext and int interfaces, and see if the packets are getting routed correctly in each direction.

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 predatorsw over 16 years ago in reply to BarryG

tcpdump? Is there a way to do that from the UI? I tend to avoid the command prompt.
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 16 years ago in reply to predatorsw

Sorry, command-line only.

You could use Wireshark on a PC, but you'd have to put a hub or tap or span-port on each side of the firewall to get the full picture.

The Wireshark and Pcap folks have a new remote sniffer interface, which would be great for this case, but it's not going to be trivial to get running.

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 predatorsw over 16 years ago in reply to BarryG

http://portal.knowledgebase.net/display/2/articleDirect/index.asp?aid=215522

This seems silly to me. Wouldn't a plain old dnat any http ip destination -> webserver work? I added in a full NAT as suggested here and it seemed to work.

That was article ID 215522, the help system while trying to help you sticks in a ton of other junk in the url.
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 16 years ago in reply to predatorsw

Yes, DNAT should work. I use it as do many others here.

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 16 years ago in reply to BarryG

This sounds similar to https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39170

Barry
Cancel
Vote Up 0 Vote Down

Cancel