Source-address any (or an address book reference)ĭestination-address any (or an address book reference)Īpplication Īs you make your rules, you might find the "insert" command useful for reordering policies. If you want to allow DMZ initiated traffic with destination ports smtp, http, https, dns(tcp/udp), then you would need something like this: Activate the "from-zone DMZ to-zone untrust" and then deactivate/activate individual policies within that group if you want to test different rules.
I'm pointing that out, because I think you might have deactivated the top level inadvertantly. You also have individual policies within that hierarchy deactivated. (This can be changed,fwiw ) You have your entire "from-zone DMZ to-zone untrust" deactivated. The default behavior for interzone traffic is deny-all. If you want to test ping to the interface from a DMZ host you will need to configure ping under the DMZ security zone. You will need to put interface vlan.1 in the DMZ security zone. I also recommend the Junos Security book as a good reference: To configure the switch for a newly minted (or recently reset) HP switch, plug in a device that is on the 192.168.2.X subnet, and then open a web browser to 192.168.2.10 (this is the default IP for this particular device check the notes for your specific switch). If you are new to the SRX, I recommend the SRX day one book: FYI, you also have a layer2 interface in the untrust zone. Make sure you create the address book entries for the above servers. The return traffic from the mail server in the trusted zone will go back to the dmz. I'm assuming smtp will be 25/TCP so we can use junos-smtp as the application. Here is an example to allow smtp to go from the dmz spam relay to the mail server in the trusted zone. Basically, if you want to allow traffic between the trust and dmz zones you will need to have a policy and appropriate rules on the side that will initiate the flow. But to answer your question about allowing smtp traffic between the DMZ and trust zones. You also have lots of inactive policies, so it is difficult to discern what you are attempting to accomplish. You have a layer 2 interface in there instead, and this is a routed firewall not a transparent firewall. App filter in place on the external vWire to allow only Active Sync and Secure-access. What happens if it needs to connect to something in the 2.2.2.It looks like you need to put in the vlan.1 interface into the DMZ zone. Currently the SSG5 forwards all traffic incoming on port 443 to the SA. So if anything connected to the 192.168.1.1 Interface wants to access the Web then it'll go out over 1.1.1.1 and will appear to the external host as 1.1.1.1 due to NAT.
|-192.168.1.1 (Interface with bunch of untrusted computers connected)Ģ.2.2.1 (Public IPs on default Trusted Interface) One final thing, and not sure how this will look in text but: The hope is to be able to also use the SSG's captive portal feature to show a basic "these are our T&Cs" page when someone accesses the web. I may give this a try tomorrow to see how well it works. It wasn't a technical reason tbh, just that we have our own IP space and prefer to use that rather than what the ISP gives us. As far as not wanting to NAT onto the one IP, consider that I've NATd several *thousand* clients to a single IP and it worked just fine.
0 kommentar(er)
