Hot Downloads



The forum is in read only mode.
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: LAN, OWA, and Firewall help

LAN, OWA, and Firewall help 14 years 3 months ago #5519

  • jhun
  • jhun's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
  • Posts: 356
  • Thank you received: 0
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.. :)

Re: LAN, OWA, and Firewall help 14 years 2 months ago #5736

  • jhun
  • jhun's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
  • Posts: 356
  • Thank you received: 0
well i haven't figured out this one yet but if you still have sugestions or comments just post away. thanks..

Re: LAN, OWA, and Firewall help 14 years 2 months ago #5742

  • nske
  • nske's Avatar
  • Offline
  • Expert Member
  • Expert Member
  • Posts: 613
  • Thank you received: 0
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 ):


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[/u]

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[/u]

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 ( and port 5000. Connections are forwarded to port 80 on server
[code:1] stream tcp nowait nobody /usr/bin/nc nc -w \
20 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 -> \ port 5000 [/code:1]

RDR and NAT Combination[/u]

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 -> \
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 :)

Re: LAN, OWA, and Firewall help 14 years 2 months ago #5888

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

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

Re: LAN, OWA, and Firewall help 14 years 2 months ago #5897

  • jhun
  • jhun's Avatar Topic Author
  • Offline
  • Senior Member
  • Senior Member
  • Posts: 356
  • Thank you received: 0
it displays the 404 error bionicthmb.."The page can not be displayed".

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

Re: LAN, OWA, and Firewall help 14 years 2 months ago #5917

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?
  • Page:
  • 1
Time to create page: 0.182 seconds


Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V


  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup