routing issue in LAN



  • Hello Everyone ,
    I have the attached setup 0_1528977716896_Pfsense.jpg

    I deployed pfsense in ESXI and disabled packet filter , if I ping from 192.168.1.1 to pc in 192.168.10.0 network I can see the traffic and ICMP reply as well but in 192.168.1.1 is request time out
    what do I missing here ?
    any help is highly appreciated
    Thanks


  • Rebel Alliance Global Moderator

    is that a typo of a gateway of .255 are you using a mask larger than /24 if /24 .255 is broadcast address.

    Is that some road warrior vpn into what? I that some vpn server on 10.10.10.20?

    If pfsense is a downstream router from this 10.10.10.20 box why is its gateway .254?



  • This gateway that you have listed as "10.10.10.255" which should probably read "10.10.10.0/24" must know the route back to the 192.168.10.0/24 network in order for your set up to work. Check that as your first step, if there is a static route already in place then the problem is somewhere else.



  • Thank you both for your response , the 255 is typo it is 254 :)

    I was suspecting the GW as I don't have a control over it , will check with the admin and see


  • Rebel Alliance Global Moderator

    Ok so 10.10.10.20 is some vpn server, and 192.168.1.1 is a what exactly? A site to site vpn off this vpn server? But pfsense is pointing to some upstream router in the 10.10.10.0/24 network?

    Then that is not going to work.. If this 192.168.1/? network is off of this 10.10.10.20 then pfsense would need a route to know to get send traffic to 10.10.10.20 to get to 192.168.1/? network



  • 192.168.1.1 is the VPN client IP , that can reach the 10.10.10.20 server successfully and the VPN server has default route 10.10.10.254 which is GW , then I have pfsense with 2 interface
    WAN 10.10.10. 98 which is DHCP address from 10.10.10.254 GW and
    LAN with 192.168.10.254
    the internal network is on 192.168.10.0 and if VPN client ping PC 192.168.10.22 , I can see that PC reply back but on the VPN client is request time out


  • Rebel Alliance Global Moderator

    exactly to get to 192.168.1.1 pfsense needs to send traffic back to 10.10.10.20, if its sends it to 10.10.10.254 how will go back down the vpn? This is why its always better to put the vpn at the edge vs some internal server.

    How is it that 10.10.10.20 knows how to get to 192.168.10? Because pfsense would nat that traffic to its 10.10.10.98 address.

    So your either going to have to create a route on pfsense to use 10.10.10.20 to get to 192.168.1/24 or your going to have to source nat on 10.10.10.20 so traffic from 192.168.1 looks like it came from 10.10.10.20 to pfsense.



  • hmm , I still can't get it work , not sure if I did the right thing though
    I created new gateway on pfsense with 10.10.10.20 IP and then created static route to 192.168.1.0 with the gateway I created. is that right ?
    Thanks


  • Rebel Alliance Global Moderator

    Yes in theory that would be correct... But what I have found over the years is users say they did X when they really did Y or something that wouldn't even be in the alphabet when they said they did X... When they actually did something more like Σ (uppercase sigma) if that doesn't look right ;)

    So without more details of your config it is not possible for me to help you find out what the root of your problem is.



  • Make sense , upon that I uploaded full file with all the details 0_1529005575738_diagram.zip
    thank you :)



  • BTW the IP are different now , and I put the a new diagram there :)


  • Rebel Alliance Global Moderator

    Your route is 192.168.1.0/32

    That is never going to work.. But since its your default it should work..

    So your remote client knows to get to 192.168.42/24 it needs to go down the tunnel. Then your VPN devices knows how to get to this as well via pfsense. And your allowing the firewalling? And your not natting at pfsense. Or are you port forward and having your client try and talk to pfsense wan IP 172.17.20.98

    So are you still having issues.. If so going to need the details ask about.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy