Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 4233 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

Policy validation ( Block internet access except if it is via VPN )

Paul C1

Hey all,

 

I want to block all internet access to a machine. The machine can only access the web if it passes via a VPN client (PIA in my case)

 

Currently I have made this setup:

with service

 

and

 

By the looks of it it works.

 

Am I missing something? Is there a better way?

 

Thanks,



This thread was automatically locked due to age.
Parents
  • 0

    XG Firewall drops all traffic if it does not find any matching rule. 

    So basically you do not need an default drop on bottom. Also there is a different between Reject and Drop. 

    http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

    But to see, who tries to reach something, you still need the drop rule. But be careful, a drop rule can cause issues in some scenario´s. So if you experience problems in your XG Firewall, just disable the drop rule and try again. 

  • 0 in reply to LuCar Toni

    Awesome info.

     

    I do need a drop/reject rule as at the bottom I have the LAN to  WAN generic policy that is not segregating by MAC addresses.

     

    Since we need DROP to be able to debug, I will just copy my REJECT policy and create a deactivated "DEBUG" policy right above it, that I can turn on when I need to debug something.

     

    Does that make sense?

     

    Again, thanks for the info.

  • 0 in reply to Paul C1

    I do not have a Default Drop on bot of my XG´s because if i want to debug something, i will go to the shell and reproduce it live on the appliance with drppkt.

  • 0 in reply to LuCar Toni

    But that doesn't capture history, does it?

    Cheers - Bob

  • 0 in reply to BAlfson

    That is true. Without default drop Policy, you do not have any "Drop packet capture" per default. 

    You could create such a log on your own with drppkt on Shell. I only use drppkt to debug but i need the live setup to see, what is going on.

    Worked couple of years with UTM9 and most of the time, i could not really resolve issues with packetfilter.log because it only covers the firewall and only the initial packets. Most of the times, you need to reproduce the issue anyways and XG has more powerful tools like drppkt, tcpdump with interfaces/direction, conntrack with more information. 

    Most of the time, i log into the XG and let the issue reproduce to see, what is going on. Personally speaking - i hate issues from the past. Digging through tons of logs to find any pattern is kinda messy.  

Reply
  • 0 in reply to BAlfson

    That is true. Without default drop Policy, you do not have any "Drop packet capture" per default. 

    You could create such a log on your own with drppkt on Shell. I only use drppkt to debug but i need the live setup to see, what is going on.

    Worked couple of years with UTM9 and most of the time, i could not really resolve issues with packetfilter.log because it only covers the firewall and only the initial packets. Most of the times, you need to reproduce the issue anyways and XG has more powerful tools like drppkt, tcpdump with interfaces/direction, conntrack with more information. 

    Most of the time, i log into the XG and let the issue reproduce to see, what is going on. Personally speaking - i hate issues from the past. Digging through tons of logs to find any pattern is kinda messy.  

Children
No Data