Routing traffic outside PIA? (Kill switch)



  • Hi All

    I am new to pfsense (I did use checkpoint many years ago thow)

    Following this excellent guide I managed to setup PIA and multiple VPN connections in Pfsense
    Youtube Video

    This also include the "Kill switch" if the OpenVPN goes down and everything works perfectly!

    BUT I really would like to create a rule for a specific IP (Host) that goes around all my OpenVPN's and uses my fixed local WAN IP?

    How do I go about this?

    My Interfaces are:
    757c66d9-2e58-4f2e-b568-34fd3354bf3d-image.png

    I tried to create a Firewall Alias for a fixed IP: 192.168.0.14
    1a80ce9a-f10e-43f0-b16d-c7050d5f91ae-image.png

    And then a LAN rule for this:
    d76d10fe-8b7e-48b2-937a-551319ffbd36-image.png

    And another Floating rule above my VPN floating rule:
    be84f850-2cc7-43e9-bc7b-84d5fc3f22ca-image.png
    5917fe45-5644-4b85-ad23-5cd4fd579805-image.png

    But no matter what I do I keep getting the Swiss OPenvpn for my 192.168.0.14 ?

    Where did I go wrong?

    Best regards
    Casperse



  • Whats under
    Firewall / NAT / Outbound ?



  • Following the video only the auto generated rules, from the VPN setup:

    4268a078-f419-4e81-8a3b-937e85d58094-image.png

    Is it something about the order of them? or am I missing one? :-)

    Thanks for trying to help me out!
    Much appreciated, I have been ad this for a week now.....



  • I think you got that tag wrong in the first firewall rule, also the floating rule shouldn't be necessary, I would disable it.
    But I could be wrong.



  • So deleting the floating rule for the "GigabitFixedIP" outside the OpenVPN connection
    But the tag "GigabitFixedIP" came from the floating rule? Then there wouldn't be any tag?
    Sorry still new to Pfsense, so I could have misunderstod where the tag should be?



  • @casperse I think tag should be in the LAN Rule and tagged in the WAN (floating-Rule), if it is needed anyway.



  • @Bob-Dig Show us your LAN rules in general.



  • I just added this to the WAN firewal rules above:
    f57678f5-8220-4cbb-90b1-177bbb47a433-image.png

    With the tag.... that didn't help either (Really impressed on how well this stops all traffic, but there must be a way :-)

    LAN RULES:
    5ba90ef6-b2af-4802-b871-ba6fbfce200b-image.png



  • @casperse You don't need tagging in the first place and not for the default gateway and your "tagging" is wrong in the LAN Rule, like I already said.
    I would advise you to undo all tagging and if everything works just use it for the "Killswitch".



  • @Bob-Dig Ok so remove all tagging (Except for the kill switch - that works)
    Delete the floating rule for this
    Should I keep both the WAN and LAN rule? (Without the tagging)
    I manually created both of them should the WAN be auto created?

    Again thanks for your patience!



  • @casperse You don't need the wan-rule.



  • Ok I have deleted all the rules and only kept the LAN rule
    (Gateway default is set to WAN)

    e5376371-16d8-424b-b4cf-73f871434ad5-image.png

    I still get connection through the OpenVPN tunnel from my test PC : 192.168.0.14
    Only if I disable the kill switch and stop the VPN service then I will get the WAN IP?

    There is something with that floating rule working as a kill switch that breaks this LAN firewall rule



  • Update: Disabling the floating "Kill switch" rule didn't make any difference
    it still goes through the OpenVPN and not the WAN IP?



  • @casperse You used the tags the wrong way, you have to tag on LAN and used tagged on WAN. Any maybe there is more not ok. 😉
    I wonder why your Killswitch worked in the first place.



  • Okay you said no Tags :-)

    I have just created two rules now (Just like used for the VPN in the video in the first post)

    1. LAN Rule with TAG:
      05ba57af-c732-4234-8b18-ee7ef3447905-image.png

    LAN rule in details:
    c8ebfce7-35de-4b7d-a3e3-2ecb292dae49-image.png

    And the Floating rule to allow this traffic setting the TAG:
    ABOVE THE KILL SWITCH
    dc9a9f9b-262b-4b52-8623-01cbe0790258-image.png

    Floating rule that reads the TAG:
    92c8173f-eea9-413d-ab85-dbd798d22a9c-image.png

    And this still doesn't work? (The Tags are correct now :-)



  • @casperse So first, this WAN rule should be totally unnecessary because you already had the default gateway in the LAN rule.
    But anyway, there seems another problem elsewhere.

    Like I said, no tagging, no floating rules, no wan rules at all and make this working first.
    Then to the killswitch.



  • Also Reset the firewall state table under DiagnosticsStatesReset States every time you test something.



  • @Bob-Dig There is no WAN rule? (Only a LAN and a floating rule for the tag)

    The killswitch is using another tag called "vpntraffic" that is why the kill switch works, this is also in each of the LAN rules for the OpenVPN rules (Everything setup like in the video and working)

    I just cant get any traffic outside the VPN tunnel.... Tags or no tags

    As I said it works if I disable the Openvpn short of doing that it always goes through the VPN?



  • @Bob-Dig Finally found the problem....

    If I test the above rules using a Laptop and not a virtual VM on my server everything works!

    My Unraid server IP is used and shared by the Docker and the same gateway (subnet) Unraid server IP: 192.168.0.6
    I have virtual machines VM's on the Unraid server with their own fixed IP like: 192.168.0.18

    If I route any traffic through the Pfsense for the server Unraid IP, dockers etc on the 192.168.0.10 it will overrule any traffic coming from my VM having IP: 192.168.0.18 and route everything over the rule set for the Unraid server IP 192.168.0.6
    hosting the VM's

    So is this only possible to route traffic from my VM's if they have a real physical NIC's that I can passthrough to my VM's?
    Or is there some traffic setting in Pfsense that can split this traffic apart?



  • @casperse
    Is it a public bridge in the vm or has is something to do with docker?
    Anyway, I would start another thread here or in Routing.


Log in to reply