Lan 1 to Lan 2 Connection Fail

tridac

John,

You asked about the stuff in the advanced section. Just a few minor changes to improve security:

None standard https management port
Randomise id field in ip packets
Insert stronger id into ip header for packets passing though the filter.

If you run zenmap against the wan port, it more or less susses out which os it is, but doesn't find much else. Going to try some of the Kali Linux stuff in the next few weeks, which may find some holes, though I doubt it. I wonder if the nsa have found a way in yet ?…

Regards,

Chris

johnpoz

What I wasn't clear in your other posts of your dumps is what actual interface you did the trace on.. Be it they were on pfsense, server or client.

Statements like this
"Pfsense console tcpdump also shows the outgoing request to the server on the interface. However, it never sees the server response."

From a common sense point of why would you be sniffing on the interface on the other side of pfsense?? Until you had validated that it had showed up on the input interface to pfsense.

This trace for example.

You state this is the trace at the server..

"Also, I did show the output from tcpdump at the server, firelight:

19:00:27.909689 IP 172.16.100.205.53942 > firelight.telnet: tcp 0
19:00:27.909804 IP firelight.telnet > 172.16.100.205.53942: tcp 0
19:00:30.914297 IP 172.16.100.205.53942 > firelight.telnet: tcp 0
19:00:30.914362 IP firelight.telnet > 172.16.100.205.53942: tcp 0"

So one statement from you says pfsense does not see the response, then you show that server sent the response.

As to you starting over - already suggested multiple times to do that.. YOU DO NOT NEED NAT!!! And from your port forward your trying to send anything going to port 23 on the "housenet net" which is the 172 space – so when would that even be hit? to the server on labnet.

And you have both tcp/udp ?? So yes I would START OVER.. And just do any any rules between your local segments.. Once that works, then you can block or allow what you want between your segments with firewall rules - not nats and or port forwards.

As to the advanced options - that is not what I am talking about.. I am talking you have set something in the advanced features of the rule.. See attached. What have you done there? Your labnet rule shows that an advanced feature was set on the rule - that is what I was asking about.

BTW - I can understanding wanting to be secure, etc. and sure if you want to use random in the IP ID, ok -- but now I might be mistaken - but pretty sure that would be changed again at your other nat since your pfsense wan is 10.x.x.x you clearly have to be doing NAT again to talk to the internet or your clients behind pfsense would have to be using a proxy to get out, etc. So your wanting to hide your OS from this 10.x.x.x network?

housenet.png_thumb

advancedfeatures.png_thumb

aflaginrule.png_thumb

tridac

I tried reinstalling with the same rules as per the screenshots and it's still not working, so have to assume for now that this configuration is not supported at present. Will just have to find a different solution for now, but if you need any more info to confirm the findings, please let me know

Thanks for the help and suggestions in any case…

Regards,

Chris

tridac

John,

Just to clear up one misunderstanding, "pfsense console tcpdump" means that tcpdump was running on the pfsense console shell. It's a built in command and part of pfsense.

The packet is definately on the wire at the lab interface, but it's not seen by the pfsense shell tcpdump, so where can it be ?…

Regards,

Chris

johnpoz

I know what tcpdump is ;) and how to run it..

And again your saying its not there.. So lets clear up where your running it..

you have

client – pfsense -- server

where you telneting from client to server..

So which interface are you running tcpdump on? the client side or the server side?

You need to run it on the server side.. If your running on server side and you see packets go out to server. And wireshark/tcpdump running on server shows it sending replies to that traffic but you don't see those reply packets on pfsense then 110% sure pfsense has NOTHING to do with your issue.

All I can say is this takes all of 3 minutes to setup.. There is NO nat between local networks.. And its simple firewall rules to allow whatever traffic you want. As I showed you when I changed my dmz segment to 172.15

I assure you that pfsense supports this setup so your doing something wrong in the config. Or you have something else wrong on your network.

I would be happy to teamviewer in and take a look if you want.

Back to the tcpdump -- if you run it on the server side and see the return traffic. But don't see it on the client side of pfsense then yeah something is wrong with pfsense. So which exact interface are you running the tcpdump on pfsense client or server labnet or homenet.. Where if can keep your networks straight homenet is the client side and your telnet server is on the labnet side.