pfSense not responding to any ports



  • Alright so this is a weird issue probably related to AWS but if anyone has any ideas off the top their head it would really help me out.

    I've got a pfSense server sitting on a subnet at the IP 10.60.66.30.

    I can reach it fine via curl from 10.60.66.9 (same subnet), getting a response back as shown:
    0_1550603470693_4aecb643-1817-4613-a940-ff1bc2cc9bbb-image.png

    I cannot get a response from a box 192.168.3.20 (different subnet):
    0_1550604352773_7afe76af-8ca0-4ba0-8ecf-426fa4bae68f-image.png

    HOWEVER, here's the kicker, the pfSense box is getting the http requests, just not responding to them:
    0_1550604451308_e4fad656-9b1a-4cb3-beee-7a5f9c82545d-image.png

    It does respond to requests from the same subnet... why?
    0_1550604511990_fd1b0d1b-bcdf-47ec-aed9-9aec63f5ffd6-image.png

    If I try to connect back from the pfSense instance to my other box, same thing, but opposite direction:
    0_1550604806262_5a617691-1710-434b-9c83-373a07074632-image.png
    0_1550604839044_9811398d-aebb-47ec-87b1-ed92cdd901fa-image.png

    However, this doesn't happen from another box on the same subnet (non-pfSense 10.60.66.9)
    0_1550604873923_264c3c77-0d24-4da0-bad5-e66bda0f989a-image.png

    I've checked the rules and the logs.. nothing apparent is popping out at me as to why it would be doing this. Why does this pfSense instance hate me?



  • Someone might be able to help you once you give them a network map to know what's where, and a screenshot of your firewall rules.



  • Here's the sketch of the network map:
    0_1550606588778_7a6fac04-19b8-42ec-8fa7-60d60cbba648-image.png

    Note: the two pfsense instances can talk to each other just fine. The two ubuntu boxes can also talk to each other just fine.

    rules on 10.60.66.30 pfsense instance:
    WAN:
    0_1550606107599_a36ffc8c-2367-42ba-b86f-8ad85d6088d7-image.png
    Floating:
    advanced setting: statetype sloppy state:
    0_1550606386442_ba812085-61f4-45a0-a355-792c2ede4809-image.png
    IPsec:
    0_1550606215998_5fa8b74d-aed9-4345-98b4-0c632dc7ea74-image.png



  • OK the network map was the first clue I had that IPSec was involved. I don't know much about IPSec, but have you already gone through the troubleshooting docs?

    https://docs.netgate.com/pfsense/en/latest/book/ipsec/ipsec-troubleshooting.html

    https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ipsec-troubleshooting.html



  • Right.. so I thought about that.. but wouldn't I still see an outgoing packet from the firewall if it were an IPSec issue? From the troubleshooting there seems to be routing enabled both ways - pfSense can send packets to Ubuntu, Ubuntu can send packets to pfSense, but neither are responding to the packets for some reason?



  • @thund3rsh0ck said in pfSense not responding to any ports:

    Right.. so I thought about that.. but wouldn't I still see an outgoing packet from the firewall if it were an IPSec issue? From the troubleshooting there seems to be routing enabled both ways - pfSense can send packets to Ubuntu, Ubuntu can send packets to pfSense, but neither are responding to the packets for some reason?

    I am confused, how can both be sending and neither responding? Are you doing PCAPs to determine this? Can 10.60.66.9 ping 10.60.66.30? Can you log into the pfSense webUI?



  • @tim-mcmanus said in pfSense not responding to any ports:

    @thund3rsh0ck said in pfSense not responding to any ports:

    Right.. so I thought about that.. but wouldn't I still see an outgoing packet from the firewall if it were an IPSec issue? From the troubleshooting there seems to be routing enabled both ways - pfSense can send packets to Ubuntu, Ubuntu can send packets to pfSense, but neither are responding to the packets for some reason?

    I am confused, how can both be sending and neither responding? Are you doing PCAPs to determine this? Can 10.60.66.9 ping 10.60.66.30? Can you log into the pfSense webUI?

    Yes - from the initial post there are tcpdumps.

    Well I know both can send, receive, but the question is why neither is responding.

    Yes 10.60.66.9 can ping 10.60.66.30
    0_1550607639005_e69cf412-b442-4e26-8cff-b8dcef66881e-image.png

    yes I can login to the pfsense webui at 10.60.66.30 from 10.60.66.9, but not from 192.168.3.20 as shown from the curl attempts.

    192.168.3.20 can't get a response from ping either, even though the pfsense instance is getting them:
    0_1550607867029_6fb626f1-7068-4b4a-83ae-fcf570a7f87a-image.png
    0_1550607947782_63bd6352-7ba4-4b62-b033-60ea3a11463f-image.png



  • Machines on the same subnet will always be able to talk to each other because they aren't routed anywhere -- they're all local.



  • What network are you using for your IPSec tunnel? Has this ever worked before or did you just install it now?



  • Yes the tunnel functions as expected, mostly to NAT internet traffic out and from the corporate firewall. I'm not even sure all the traffic we're talking about here is being routed through those tunnels, probably via the VPC to VPC peering connection instead (which is what the ipsec tunnel is using as well).



  • @kom said in pfSense not responding to any ports:

    Machines on the same subnet will always be able to talk to each other because they aren't routed anywhere -- they're all local.

    I just had to ask because I didn't completely understand where we were with troubleshooting. Had to start with the basics.

    My guess is that one or both of the tunnels does not have routing configured properly. I don't have IPsec configured on my router anymore, but I believe you need to set the routing up there as well as creating firewall rules.



  • I don't have the time to dig deep into this and I'm not really an IPSec guy, but my first random guess would be asynchronous routing.



  • @kom said in pfSense not responding to any ports:

    I don't have the time to dig deep into this and I'm not really an IPSec guy, but my first random guess would be asynchronous routing.

    yeah I've had some trouble with packets going back and forth via different routes due to the complex routing config here... which is why I had to mess with some of the sloppy state firewall rules. However, those were all caught by the firewall and logged. The puzzler here is nothing is showing in the firewall logs this time.. so I don't even know where to start to try and fix it.

    The part I can't figure out is why there is no response caught by tcpdump. Even if the packet is lost in routing, shouldn't there still be an outbound packet? Also.. one-way connections work both ways which is also odd. Argh.. what a headscratcher.


Log in to reply