Unable to access internet from remote site



  • Hi, first post here.
    We've been using pfSense at our company for a couple of days now. So far it's been working great.
    A big thanks to all you guys whos been putting so much effort into this great product. :)

    Everything is working like we hoped for except one small thing.
    We cannot access internet from a remote subnet.
    The subnet is connected via a router and when I do a traceroute from that site to a host on the internet the last reply I get is from the pfSense box after that it just times out.
    I think I've set up all the needed routes, rules and such.
    To get the internet working on the remote site I hade to install squid and then set up the browsers with proxy settings.
    This works temporarily but will not work in the long run sinze we have applications that arn't proxy-aware.

    Could someone give me some pointers to what might cause this problem?

    Thanks!



  • @PhatBot:

    We cannot access internet from a remote subnet.

    I think I've set up all the needed routes, rules and such.

    Use the latest beta if it should be a pfsense issue

    Post your routes, rules and such. :)  a bit hard to know what you have done so fare.



  • You need to make sure the static route(s) for these subnet(s) are entered properly, and also change the default LAN permit rule so it allows more than just the LAN subnet. by default only the subnet directly connected on the LAN is permitted out by the firewall rules.



  • Thanks for the reply guys.
    Lets see if I can describe it better…

    Interfaces:
    IF1(WAN) - IP XXX.XXX.XXX.XXX
    IF2(LAN) - IP 10.58.112.5/22
    IF3(DMZ) - IP 192.168.0.1/24

    Routes:
    LAN 10.58.118.0/24 GW 10.58.112.12
    LAN 10.58.204.0/24 GW 10.58.112.12
    LAN 10.58.202.0/24 GW 10.58.112.1

    NAT: (Advanced outbound)
    WAN 10.58.0.0/16 * * * * * NO    (LAN -> WAN)
    WAN 192.168.0.0/24 * * * * * NO (DMZ ->WAN)

    Rules: (on LAN IF)

    • 10.58.0.0/16 * * * * * (Allow all out)

    10.58.118.0/24 and 10.58.204.0/24 comes over VLAN via a routing switch with IP 10.58.112.12
    10.58.202./24 comes in via a leased line through a router with IP 10.58.112.1

    Entire LAN, 10.58.118.0/24 and 10.58.204.0/24 works flawlessly in every sense. However 10.58.202.0/24 never passes through the pfSense. It's like it refuses to do NAT for that subnet.

    Hope this describes it better.

    Thanks again!



  • bump  :)



  • can you ping IP's on those subnets from pfsense itself?

    Do you see the traffic getting dropped in your firewall log?



  • Yes, pinging from pfSense to the remote subnet works just fine.
    And no, the log show thats the traffic gets through.



  • Based on what you said, your pfsense sounds fine. I didn't see it mentioned, what version are you running?



  • Version 1.0.1

    Well it seems like it's doing fine yet it doesn't seem to NAT that subnet.

    Can't really see any other things in my network typology that could cause this problem.





  • Ok upgraded to 1.2-Beta-1 (Excellent job on the firmware upgrade routine guys. Quick and accurate.)

    Still no go though.
    Passes firewall rules but seems to get stuck in NAT or something.



  • Yeah I would have suspected a NAT bug in 1.0.1, there are a few of those that have been fixed in 1.2b1.

    Do you have advanced outbound NAT enabled?



  • Yes, advanced NAT enabled.



  • Then it's a problem with your advanced NAT rules. Do you need it for some reason? If not, just disable it and your problem goes away.



  • Changed to normal NAT.
    Still same problem though.

    Very odd.



  • Is there be anything special with that leased line?

    10.58.202./24 comes in via a leased line through a router with IP 10.58.112.1

    maybe do some trace with pftop or tcpdump ( just a though )



  • Yeah it's time to start capturing packets and seeing what's really happening.



  • Right… hehe... the thing is.....  :-\

    I havn't got a clue how to do that.???
    Could someone give me some pointers?

    Thanks!

    Also. Thanks for the help on this subject. I really appreciate you guys taking your free time to help me. :)



  • Tried some TCPDUMP. Not really sure what to look for though.

    The thing I find strange is that I'm able to ping hosts on the remote subnet from the pfsense box.
    And the pfsense box also replies to pings from the remote subnet.
    Feels like the data is flowing like it should in our internal network.
    It just doesn't let me do nat for that subnet.



  • In the Webgui Diagnostics: Show States I see
    ICMP 10.58.202.21:512 -> external-ip:35350 -> external-gw 0:0
    ICMP external-gw:512 <- 10.58.202.21 0:0
    when I try to ping from the host on the remote subnet to our ISP gateway.
    This should indicate that NAT is working like it should right?



  • to check for a dns problem you could do something like this.

    from shell tcpdump -i if2 dst port 21

    from a client ftp://204.152.184.73/

    By that your can see what happens on IF2 when you logon to a ftpserver

    –--------------------------------------

    http://your-pfsense-ip/status.php

    you might find something under pfctl
    –------ !! Warning this is written by someone sitting in the sun  !! ------------



  • Tried some 1:1 NATing.
    Worked like a charm for all our subnets except the remote subnet which we have the trouble with.
    Starting to think that there must be something fishy with the router thats handling that subnet.

    More info later.



  • Hi Perry,

    Here's the result after dumping it to a file and then importing it into Etherreal.




  • did you try searching in http://your-pfsense-ip/status.php for 10.58.202.21 or 204.152.184.73 after the test, there must be some info there telling us what happens  ::)

    your can also use
    Diagnostics -> Packet Capture
    to trace ip's



  • Here is what I see in status.php during a attempt to connect to an external ftp site.
    I've replaced real IP with "externa_ftp"

    pass in log quick on bge0 inet from 10.58.202.21 to any keep state label "USER_RULE: Log all from 10.58.202.21"
    self tcp 127.0.0.1:8021 <- external_ftp:21 <- 10.58.202.21:3530       SYN_SENT:ESTABLISHED
    USER_RULE: Log all from 10.58.202.21 65739 49 2352
    142 pass in log quick on bge0 inet from 10.58.202.21 to any keep state label "USER_RULE: Log all from 10.58.202.21"
    tcp   I 10.58.202.21:3530     127.0.0.1:8021        2:4      4    29     4   192
    tcp    In  10.58.202.21:3530      127.0.0.1:8021         external_ftp:21           SYN_SENT:ESTABLISHED  00:00:04  00:00:29       4     192     48 142
    tcp       In  10.58.202.21:3530                     127.0.0.1:8021                          SYN_SENT:ESTABLISHED  00:00:05  00:00:28        4      192
    142                  Pass     In  Log Q bge0             K       49     2352        1       inet from 10.58.202.21/32 to anycp    In  10.58.202.21:3530      127.0.0.1:8021               4     192    SYN_SENT:ESTABLISHED  00:00:05  00:00:28      38 142 external_ftp:21
    tcp    In  10.58.202.21:3530      127.0.0.1:8021               4     192    SYN_SENT:ESTABLISHED  00:00:05  00:00:28      38 142 external_ftp:21
    tcp    In  10.58.202.21:3530      127.0.0.1:8021              38     192    SYN_SENT:ESTABLISHED       4  00:00:05  00:00:28 142 external_ftp:21
    May 31 14:57:12 gatekeeper1 pf: 88\. 107669 rule 142/0(match): pass in on bge0: 10.58.202.21.3444 > 127.0.0.1.8021: S 2654838692:2654838692(0) win 65535 <mss 1460,nop,nop,sackok="">
    May 31 14:59:35 gatekeeper1 pf: 2\. 114729 rule 142/0(match): pass in on bge0: 10.58.202.21.3530 > 127.0.0.1.8021: S 3010410930:3010410930(0) win 65535 <mss 1460,nop,nop,sackok="">
    pass in log quick on $lan from {  10.58.202.21 } to any keep state  label "USER_RULE: Log all from 10.58.202.21"</mss></mss>
    


  • For me it looks like it nat's to the wan instead of going out

    tcp    In  10.58.202.21:3530      127.0.0.1:8021        external_ftp:21
    should be
    tcp    In  10.58.202.21:3530      127.0.0.1:8021        204.152.184.73:21

    but since your running nat1:1 i could be completely wrong on how it should look

    I'll Better let the dev's step in now  ;)



  • 1:1 NAT was only temporarily while testing.
    Those rules were removed before getting this status. So it shouldn't do anything.


Log in to reply