LAN, OWA, and Firewall help

hi to all

currently i've setup OWA (Outlook Web Access) on our SBS Server working concurrently with our Sonicwall SOHO3 firewall. Outside our LAN the URL works fine, however when someone browses within our LAN which is in a domain level, the URL does not work. The only workaround to this is to type the intranet address of our SBS server to access the OWA service (e.g http://*ip address of server* or http://*server name*.

I'm thinking that there is something in the access rules set in the Sonicwall SOHO3 firewall that blocks my defined OWA site. How may I be able to go aobut this?..Any suggestions and/or comments would be highly appreciated.

thank you very much..

well i haven't figured out this one yet but if you still have sugestions or comments just post away. thanks..

ah I hadn't noticed your post

That happens most likely because NAT/Port Forwarding is done on the Public Interface, so to take place, something has to actually pass through that interface, in other words, go from the inside to the outside or from the outside to the inside.

On OpenBSD's PF manual several possible workarounds are mentioned.

here is the relative part (quoted from PF manual at www.openbsd.org ):

...

There are several solutions for this problem:

Split-Horizon DNS

It's possible to configure DNS servers to answer queries from local hosts differently than external queries so that local clients will receive the internal server's address during name resolution. They will then connect directly to the local server, and the firewall isn't involved at all. This reduces local traffic since packets don't have to be sent through the firewall.

Moving the Server Into a Separate Local Network

Adding an additional network interface to the firewall and moving the local server from the client's network into a dedicated network (DMZ) allows redirecting of connections from local clients in the same way as the redirection of external connections. Use of separate networks has several advantages, including improving security by isolating the server from the remaining local hosts. Should the server (which in our case is reachable from the Internet) ever become compromised, it can't access other local hosts directly as all connections have to pass through the firewall.

TCP Proxying

A generic TCP proxy can be setup on the firewall, either listening on the port to be forwarded or getting connections on the internal interface redirected to the port it's listening on. When a local client connects to the firewall, the proxy accepts the connection, establishes a second connection to the internal server, and forwards data between those two connections.

Simple proxies can be created using inetd( 8 ) and nc(1). The following /etc/inetd.conf entry creates a listening socket bound to the loopback address (127.0.0.1) and port 5000. Connections are forwarded to port 80 on server 192.168.1.10.
[code:1]127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \
20 192.168.1.10 80 [/code:1]

The following redirection rule forwards port 80 on the internal interface to the proxy:

[code:1]rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000 [/code:1]

RDR and NAT Combination

With an additional NAT rule on the internal interface, the lacking source address translation described above can be achieved.
[code:1]rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
$server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> \
$int_if [/code:1]

This will cause the initial packet from the client to be translated again when it's forwarded back through the internal interface, replacing the client's source address with the firewall's internal address. The internal server will reply back to the firewall, which can reverse both NAT and RDR translations when forwarding to the local client. This construct is rather complex as it creates two separate states for each reflected connection. Care must be taken to prevent the NAT rule from applying to other traffic, for instance connections originating from external hosts (through other redirections) or the firewall itself. Note that the rdr rule above will cause the TCP/IP stack to see packets arriving on the internal interface with a destination address inside the internal network.

In general, the previously mentioned solutions should be used instead.

The rule examples above are with the syntax of PF, but I hope you get the idea

Try creating a CNAME record on your local DNS server that points to the SBS server. Something like "owa.mydomain.com" or "mail.mydomain.com".

When you say the URL does not work... what error message do you receive?

it displays the 404 error bionicthmb.."The page can not be displayed".

thanks fro the help and responses...i'll try your suggestions..

What IP is reported by 'ping' if you run it against the URL of your OWA? Is it the same as the internal IP address of the server that hosts OWA?