Possible NAT Bug ?
-
Doesn't sound like a NAT bug. Sounds like either the outgoing connection is being sourced from WAN or similar.
If you are using FreeRADIUS on pfSense, have it bind to * or 127.0.0.1 and specify 127.0.0.1 as the RADIUS server in CP or whatever you are using as the RADIUS client.
Thanks jimp for your reply
i do not see the logic of it being sourced from live ip/wan ip.. when all the source and destination lies on lan interfaces..
moreover radtest passess//here is a video that i made to illustrate the problem ..
https://drive.google.com/file/d/0Bwq-CrqiCEEGUUlzdW5LQ2E1bFk/view?usp=sharing
-
:-\
can somone shed some light on the video that i uploaded ?
-
will appreciate if someone could help me understand about my case as i explained in video link shraed above.
-
nobody going to watch some video to be honest.. Post some screenshots if you want convey some settings or output of a command or test, etc.
Video is not a good medium for troubleshooting stuff like that.. Need to see the settings, need to see the output of a test command, etc. Don't have to time to go back and forth in a video to look at these things, etc..
As to jimp logic of loopback.. If what is asking freerad is running on pfsense, then there is no reason what so ever to not have it just talk to the loopback address. Only reason freerad needs to listen on anything other than loopback is other devices talk to it.. Kind of hard for your AP to talk to 127.0.0.1
But seems only thing you have asking freerad is pfsense itself, so why would not just listen on loop that way you don't have ANY security concerns of anything else talking to it.
-
nobody going to watch some video to be honest.. Post some screenshots if you want convey some settings or output of a command or test, etc.
Video is not a good medium for troubleshooting stuff like that.. Need to see the settings, need to see the output of a test command, etc. Don't have to time to go back and forth in a video to look at these things, etc..
As to jimp logic of loopback.. If what is asking freerad is running on pfsense, then there is no reason what so ever to not have it just talk to the loopback address. Only reason freerad needs to listen on anything other than loopback is other devices talk to it.. Kind of hard for your AP to talk to 127.0.0.1
But seems only thing you have asking freerad is pfsense itself, so why would not just listen on loop that way you don't have ANY security concerns of anything else talking to it.
i thought it might be easier and convey more information.. though pics/text may give quick info.
here are the snaps of my configuraiton
i am uploading my configuration pics and the logs with simple problem description.
my pfsense is broadcasting 4 ssids. on one ssid i have set authentication to freeradius installed on same system.
when i authenticate to this ssid i am unable to do so. my ssystem logs shows that the requests originated from live ip.subnet of ssid is 192.168.11.0/24 ..
i also added 127.0.0.1 in NAS Clients and interfaces but still same error
if i add my wan ip (which is dynamic) to nas clients i am able to authenticate ..
my question : why was nating performed when the request was originated from local subnet (defined on pfsense ) to another local subnet (defined on same pfsense) ?
i am at loss to figure out the reason.
 -
And again why do you have it listen on 11.1 ? And why do you have a nas client setup for 11.1 ?? Why would you do that??
Curious why you have your mtu set to 1492 as a side note..
Remove 11.1 from client and interface - you have no need to for it since you have nothing other then pfsense asking for auth.
-
And again why do you have it listen on 11.1 ? And why do you have a nas client setup for 11.1 ?? Why would you do that??
Curious why you have your mtu set to 1492 as a side note..
Remove 11.1 from client and interface - you have no need to for it since you have nothing other then pfsense asking for auth.
thanks i removed those two .. i tought my free radius server ip can be any IP Defined in the pfsense on any interface .. that is why i assigned one of the lan ip as my freeradius ip in ap3 interface… and allowd this interface as nas client and also started to listen on it..
i removed those seetings .. in interface i assigned clone 3 i assgined 127.0.0.1 and also allowd this a nas client and also listening on this interface..things are working now...
my main issue is revolved..
however out of curosity why it nated traffic when source/dest ip were same ? (packet was sourced from intfce 192.168.11.1 and destination was freedradius server 192.168.11.1 )..
i have set it to avoid too much fragmentation..
http://networkengineering.stackexchange.com/questions/8288/difference-between-mss-and-mtu
http://www.tp-link.us/FAQ-190.html -
"i have set it to avoid too much fragmentation.."
So your isp connection is a problem, you have a PPPoE connection or something else that doesn't support 1500? Since wifi has no issues with running 1500 mtu..
-
"i have set it to avoid too much fragmentation.."
So your isp connection is a problem, you have a PPPoE connection or something else that doesn't support 1500? Since wifi has no issues with running 1500 mtu..
when i set mtu on pfsene to 1500 and i did a ping test to few random wan ips with no fragment option set in ping command ping were unsucessfull .
they were complaining that no fragment bit is set but data needs to be fragented ..ping -f 8.8.8.8 -l 1500
Pinging 8.8.8.8 with 1500 bytes of data:
Packet needs to be fragmented but DF set.there is no problem in letting it set to that mtu but thats not ideal .. as a packet having mtu 1500 that the router receives will be broken into two packets and the second packet will only hold few bits of data and that would be an overhead bnadwidht and processing wise considering the ipv4 packets fields that would be reapplied to that little chunk ..
through above command i found that 1464 is the mtu that will go through without being broken into parts/chunks.
mtu size can be pushed via Group policy in Windows environment.
its good to have it pused on systems that are on corporate lan .. not good for wifi users if other networks use standard mtu. -
You do understand setting it on that wifi interface now all traffic that is not to the internet were your low mtu is is at that lower mtu.. So your setting all your devices on your network to use a mtu of 1492 because your internet connection has some overhead on it? Why don't you just let the router do what its suppose to do and fragment the packets..
PMTUD should to be honest handle issues to upstream mtu size, and if you have a issue on your internet connection with lower than 1500 mtu you can just use the MSS clamping feature.. vs altering the mtu to lower than 1500 on every device on your network…
