Custom IPsec policy not allowing me to get intenret resolution

[David]

I created a policy excatly from this web site address:
http://www.microsoft.com/serviceproviders/columns/using_ip
sec.asp and even added a permit filter action to port 53
in addition to what was recommended to do from the web
site.

Layout....

80 permit
443 permit
53 inbound from my IP to any address permit
53 outbound from any address to my IP permit
all inbound traffic permit
all inbound traffic block

Finally when i assigh the policy I loose internet
connectivity????

Any help for solving or clearifing the concept for me
would appreciated. It would make sense to me that if
IPSEC is for internet security then it should also allow
me access to the internet while protecting me from
internet vulnerabilities.

 

[Guest]

Hi David
You're right when you say that ipsec should protect you and at the same time allow you connectivity, but when you're new to it, its hard to get it working correctly. First off, the most specific filter has priority, so its not the best choice to put an "all inbound blocked" together with an "all inbound permit". Should "all inbound permit" take priority you would have no protection at all from internet attacks. Second, for tcp connections you need one filter set to permit inbound, if you are operating a service, or outbound if you're a client of said service. For instance, for a web server, a secure and semi-functional policy would be
1. All inbound blocke
2. Permit inbound to port 80 from any IP (from any port, to my ip
4. ...other services..
However, the web server might also need to initiate an http connection so you'd add
3. Permit outbound to port 80 from my ip address (to any ip, from any port
A workstation, on the other hand, should drop no. 2, cause it would be a vulnerability for a non-server. For udp connections, the equivalent of no. 2 and 3 are always needed, regardless of the computer role, due to the fact that given a udp packet the filter cannot determine if you're the server or the client. This is precisely the case of dns on port 53, for which you also need to allow its tcp "fallback" variant

Well, I hope that helps.

 

[david]

Dude,

thanks allot that did the trick!

David,

-----Original Message-----
Hi David.
You're right when you say that ipsec should protect you

and at the same time allow you connectivity, but when
you're new to it, its hard to get it working correctly.
First off, the most specific filter has priority, so its
not the best choice to put an "all inbound blocked"
together with an "all inbound permit". Should "all
inbound permit" take priority you would have no
protection at all from internet attacks. Second, for tcp
connections you need one filter set to permit inbound, if
you are operating a service, or outbound if you're a
client of said service. For instance, for a web server,
a secure and semi-functional policy would be:

1. All inbound blocked
2. Permit inbound to port 80 from any IP (from any port, to my ip)
4. ...other services...
However, the web server might also need to initiate an http connection so you'd add:
3. Permit outbound to port 80 from my ip address (to any ip, from any port)
A workstation, on the other hand, should drop no. 2,

cause it would be a vulnerability for a non-server. For
udp connections, the equivalent of no. 2 and 3 are always
needed, regardless of the computer role, due to the fact
that given a udp packet the filter cannot determine if
you're the server or the client. This is precisely the
case of dns on port 53, for which you also need to allow
its tcp "fallback" variant.

 

[david]

Dude,

thanks allot that did the trick!

David,

-----Original Message-----
Hi David.
You're right when you say that ipsec should protect you

and at the same time allow you connectivity, but when
you're new to it, its hard to get it working correctly.
First off, the most specific filter has priority, so its
not the best choice to put an "all inbound blocked"
together with an "all inbound permit". Should "all
inbound permit" take priority you would have no
protection at all from internet attacks. Second, for tcp
connections you need one filter set to permit inbound, if
you are operating a service, or outbound if you're a
client of said service. For instance, for a web server,
a secure and semi-functional policy would be:

1. All inbound blocked
2. Permit inbound to port 80 from any IP (from any port, to my ip)
4. ...other services...
However, the web server might also need to initiate an http connection so you'd add:
3. Permit outbound to port 80 from my ip address (to any ip, from any port)
A workstation, on the other hand, should drop no. 2,

cause it would be a vulnerability for a non-server. For
udp connections, the equivalent of no. 2 and 3 are always
needed, regardless of the computer role, due to the fact
that given a udp packet the filter cannot determine if
you're the server or the client. This is precisely the
case of dns on port 53, for which you also need to allow
its tcp "fallback" variant.