Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 21 replies
  • Subscribers 2 subscribers
  • Views 20374 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

Firewall/Routing Issues

mvrasmussen
Hello

I'm trying to implement a 220 firewall instead of our existing iptables (ClearOS) based firewall machine (it's a bit unstable)

Our setup is primarely based on a DMZ and a internal LAN

Our hosting provider hosts the network gateway (.1) because we are doing some telephony services, and we have not direct access to this.

All our servers (primarely application and web servers) are connected via the DMZ and have a external ip defined (ex: 10.20.30.10) (not the real ip)

Our database servers is placed in the LAN with 192.168.0.* adresses.

I've tried to illustrate the setup in the attached document.

I have replicated all the forward rules from our old firewall into the "Firewall -> Rules" section along with a couple of DNAT rules.

Ex could be  ->  ->  allow

I have also made some  ->  ->  ALLOW rules

But when i try to replace the old firewall with this, nothing works, and the log displays everything is Default DROP'ed

What am i missing? Static Routes?

Please advice


This thread was automatically locked due to age.
Parents
  • 0
    The addresses are confusing for me, too.  To represent internal addresses use things like X.Y.11.22, and, for public IPs, things like 93.A.B.44.

    You're right that you only need Firewall rules.  If your Cisco routes the DMZ subnet via the External interface of the ASG, then you're right you don't need to bridge the Astaro interfaces.  If you use bridging, then you can't use Quality-of-Service.

    The one change I'd make in Corey3443's list of instructions would be to use 'DMZ -> Any -> Internet : Allow' instead of the combination of an Any-Allow rule preceded by a Lan-Drop rule.

    And, Yes, in general, never bind a Host/Network definition to a specific interface.  Always use 'Interface: >' unless otherwise instructed by an Astaro Support Engineer.  Where a definition bound to an interface is needed, that should be done with an Additional Address on the interface, and the WebAdmin-created object, like "Internal [Additional] (Address)", used.  If you have anti-spoofing disabled, then binding definitions to the Internal interface can prevent spoofing by outside devices, but there are a lot of other details that can result in strange behavior.

    Cheers - Bob
  • 0 in reply to BAlfson
    The one change I'd make in mvrasmussen's list of instructions would be to use 'DMZ -> Any -> Internet : Allow' instead of the combination of an Any-Allow rule preceded by a Lan-Drop rule.


    Other than less rules, any real advantage in doing this? and where talking about Internet IPv4 object yea?
    Because i know one advantage of having the drop rules, is you can disable logs for that rule, which will stop the spam for more critical areas.
    For example, on my dmz i would drop packet logs, because i dont care, but on my secure lan i would rather see whats being dropped.
Reply
  • 0 in reply to BAlfson
    The one change I'd make in mvrasmussen's list of instructions would be to use 'DMZ -> Any -> Internet : Allow' instead of the combination of an Any-Allow rule preceded by a Lan-Drop rule.


    Other than less rules, any real advantage in doing this? and where talking about Internet IPv4 object yea?
    Because i know one advantage of having the drop rules, is you can disable logs for that rule, which will stop the spam for more critical areas.
    For example, on my dmz i would drop packet logs, because i dont care, but on my secure lan i would rather see whats being dropped.
Children
No Data