[SOLVED] Avoiding VPN traffic going via default gateway



  • Hi,

    I've got two pfSense 1.2.3 routers at different locations with an OpenVPN link between them.

    Everything is fine except when the VPN is occasionally down. In that case I see inter-site traffic being routed silently into the open world via the default gateway.

    I tend to consider it a security issue and would rather prefer the router to say frankly that the other site network is not accessible than making private traffic available to the public.

    I have tried to enforce inter-site routes with extra "System / Static routes" entries, but they did not help, as 'netstat -r' reports all inter-site routes vanish with VPN being down.

    I believe my concern to be quite common, but unfortunately could not find an answer.

    Any ideas how to prevent private traffic going via default gateway?

    Thanks in advance,
    Sergey



  • You could add a less specific static route to route to 127.0.0.1. i.e. if your remote VPN subnet is 10.0.0.0/24, add a static route for 10.0.0.0/8 to 127.0.0.1. Then if the /24 route isn't there, it'll use the /8 route.



  • @cmb:

    You could add a less specific static route to route to 127.0.0.1. i.e. if your remote VPN subnet is 10.0.0.0/24, add a static route for 10.0.0.0/8 to 127.0.0.1. Then if the /24 route isn't there, it'll use the /8 route.

    Thank you cmb, this is the only pill that helped with the trouble so far. The traceroute listing looks rather unusual though… :) Could you give me a push in the direction where I could read more on routing priorities in pfSense?

    I have also tried "policy routing" and found that it does not help. At least for me. I have added two firewall rules on top of the list for LAN and WLAN:

    
    pass   * admitted_hosts * other_site_network * vpn_interface
    reject * any            * other_site_network * *
    
    

    Unfortunately this does not prevent 'traceroute some_host_at_another_site' from going via default gateway at WAN if VPN is down… Looks like a bug to me... Or may I be missing something? Should I start another thread for this issue?



  • That isn't specific to pfSense, that's how routing works.  A more specific (longer) netmask always has priority over a less specific (shorter) netmask.



  • If the packet is routed to 127.0.0.1, i.e. to pfSense itself, what will happen to this packet? Dropped? Re-routed according to current routing table to 127.0.0.1 again?



  • @Evgeny:

    If the packet is routed to 127.0.0.1, i.e. to pfSense itself, what will happen to this packet? Dropped? Re-routed according to current routing table to 127.0.0.1 again?

    It'll send a "destination unreachable" back to the initiating host and drop the traffic.



  • @cmb:

    @Evgeny:

    If the packet is routed to 127.0.0.1, i.e. to pfSense itself, what will happen to this packet? Dropped? Re-routed according to current routing table to 127.0.0.1 again?

    It'll send a "destination unreachable" back to the initiating host and drop the traffic.

    Gentlemen, thank you for looking into my issue and sorry for slow responding, as I am on vacation now…

    I would also expect something like "destination unreachable" to be sent back, but it looks like things happen in a more complicated way.

    On one hand, telnet from pfSense to an unreachable host predictably reports of no route being available:

    # telnet -e ^] 10.1.1.2 80
    Telnet escape character is '^]'.
    Trying 10.1.1.2...
    telnet: connect to address 10.1.1.2: No route to host
    telnet: Unable to connect to remote host
    #
    

    On the other hand, traceroute to the same host results in a series of 64 almost identic responses from 127.0.0.1:

    # traceroute 10.1.1.2
    traceroute to 10.1.1.2 (10.1.1.2), 64 hops max, 40 byte packets
     1  localhost (127.0.0.1)  0.410 ms  0.485 ms  0.449 ms
     2  localhost (127.0.0.1)  0.420 ms  0.432 ms  0.547 ms
    ...
    64  localhost (127.0.0.1)  8.310 ms  8.091 ms  8.215 ms
    #
    

    The behavior of ping is even more unusual and exhibits a loop exhausted by TTL:

    # ping -c 1 10.1.1.2
    PING 10.1.1.2 (10.1.1.2): 56 data bytes
    36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 127.0.0.1)
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 0054 b76e   0 0000  40  01 3937 127.0.0.1  10.1.1.2
    
    36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 127.0.0.1)
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 0054 d066   0 0000  3f  01 213f 127.0.0.1  10.1.1.2
    ...
    36 bytes from localhost (127.0.0.1): Time to live exceeded
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 5400 e458   0 0000  01  01 4b4d 127.0.0.1  10.1.1.2
    
    --- 10.1.1.2 ping statistics ---
    1 packets transmitted, 0 packets received, 100.0% packet loss
    #
    
    

    Finally it does not look dangerous, though is not as straightforward as might be wished…

    Any ideas if preventing VPN traffic from sneaking via default gateway might be done in a more straightforward manner?



  • This is what I was afraid of - routing loop.



  • Oh, that behaves different from inside the network than it does for traffic actually initiated by the firewall. Still the result is the same, that traffic isn't going out the Internet, and the ICMP redirect it's sending isn't going to hurt anything.


Locked