Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 1799 views
  • Users 0 members are here
Options
Suggested
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

Packet Filter Access Options

Stevey
Hi All

I'm trying to set up simple https access from the internet to my internal Win 2k3 exchange server to allow OWA or Outlook Anywhere.  I've used DNAT to route the traffic from port 443 to the internal server but am now wondering what options I have in order to restrict unauthorised traffic using the packet filter.  

So far I've tried:


  • The Active Directory user authentication but I can't work out if I can use it on the packet filter.
  • I've restricted access to know IP addresses but I have had a problem with dynamic IP addresses so this is somewhat problematic.


[:S] Am I missing something obvious? I've been trawling through the manual and this forum but can't see anything that helps.  Basically is there any way I can allow packets on the packet filter using known features of a computer, eg the MAC address or authenticating based on a locally user in the Astaro box.

BTW I know I could rely solely on the win2k3 authentication but I am a bit reluctant to leave that to a microsoft system. [:O]

Cheers
Steve


This thread was automatically locked due to age.
Parents
  • 0
    Not sure of your level of Astaro knowledge...

    With SNAT rules, the packet filter is applied first, but with DNAT rules, after.  Do you have a packet filter rule that allows the traffic you want to allow?

    I believe the accepted, safest, solution to facilitating OWA traffic is a DNAT rule with an additional IP on the external interface and a packet filter rule allowing all such traffic to the internal IIS server with the OWA website.
Reply
  • 0
    Not sure of your level of Astaro knowledge...

    With SNAT rules, the packet filter is applied first, but with DNAT rules, after.  Do you have a packet filter rule that allows the traffic you want to allow?

    I believe the accepted, safest, solution to facilitating OWA traffic is a DNAT rule with an additional IP on the external interface and a packet filter rule allowing all such traffic to the internal IIS server with the OWA website.
Children
  • 0 in reply to BAlfson
    Not sure of your level of Astaro knowledge...


    Hi BAlfson

    Thanks for the reply.  I would describe myself as a enthusiastic but not greatly experienced user so I'm struggling a bit [:S]


    With SNAT rules, the packet filter is applied first, but with DNAT rules, after.  Do you have a packet filter rule that allows the traffic you want to allow?


    I've currently got a DNAT rule:


    Traffic Source: Any
    Traffic Service: HTTPS
    Traffic Destination: External (WAN) (Network)

    NAT mode: DNAT (Destination)

    Destination: MyMailServer
    Destination Service: HTTPS

    I've used the automatic packet filter rule.

    I believe the accepted, safest, solution to facilitating OWA traffic is a DNAT rule with an additional IP on the external interface and a packet filter rule allowing all such traffic to the internal IIS server with the OWA website.


    I've think I've done most of that except I'm not exactly sure about the additional IP on the external interface.  I've been given a static IP by my ISP so I'm only using that at the moment.

    I suppose in a nutshell what I'm after is to know if I can restrict the HTTPS access only from known sources and drop the rest before it even gets to my mailserver.  

    I will only want traffic from company owned laptops and previously authorised home users so it is no problem to tweak browsers on the connecting machines, install a user certificate on  or something that could indicate that the traffic is coming from a known user.  

    I have tried restricting by IP but most of the users will be on dynamic IPs so that becomes a bit of a nightmare for me to administer.

    Hope this all makes sense

    Stevey
  • 0 in reply to Stevey
    You could use VPN clients on the connecting devices but that's a bit painful for users.
  • 0 in reply to Simon Shaw
    Thanks for the VPN suggestion. I've been using PPTP, Hamachi and the Astaro OpenVPN but I do get a lot of complaints about the speed and the reliability is a bit patchy.

    I was hoping the OWA option would be a bit more sprightly.
  • 0 in reply to Stevey
    Re: OpenVPN: Note that there does seem to be an issue between Norton Internet Security and the OpenVPN client on XP computers.  It simply doesn't always connect.  Removing NIS resolves that issue.  (BTW - I've worked with Symantec on this - so they state they're aware of it as an issue, but I don't know about a resolution)

    I am also not comfortable with OWA open to the world and would welcome any additional security options / configuration in this area.  A complex password is a good option for use on known devices (company laptops, etc.).  But you're correct that that's no solution on a "public" computer.
  • 0 in reply to eganders_01
    I just remembered that the following thread would help you set up OWA.  My guess is that you've accomplished what you need already, but here you go:
    Using iPhone 3G with Exchange ActiveSync

    Cheers - Bob
  • 0 in reply to BAlfson
    The Best way probably be to take the tick out of Automatic Packet Filter rule - That means the packet will come in on the interface DNAT to the Internal Host, but would need a packet filter rule first also. Here is where you could do alot of limiting.
  • 0 in reply to xandrosx
    Sorry for the lateness of reply.  I've been off work.

    I've been thinking about what I am trying to achieve and I realised that if I use the packet filter, I can only filter on what the normal contents of a packet are.  Duh sorry it took so long to click.

    What i've implemented is to filter by IPs using DynDNS.  eg my director's home router has a dynDNS  of directors.aficticiousDynDNS.org, then I can filter by that with the packet filter.  This seems to work.  

    This strategy is a bit more cumbersome with road warrior laptops using USB broadband dongles.  I've used the DynDNS updater tool to update the current dynamic IP of the laptop and it takes a minute or so to get to the astaro but works with a bit of patience.  Not so elegant but at least I can drop any unwanted https traffic.