Cannot NAT trough OPT1 interface on multiwan
-
Yeah it should be on that build or newer.
-
Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.
Is there anything else I should be looking at?
-
Unfortunately, this still doesn't seem to be working for me. I've tried used the automatically generated linked rule and manually creating a floating rule, but nomatter what I try it is still not working for me on the October 16th 09:56:37 version.
Is there anything else I should be looking at?
Follow the bug report also: https://redmine.pfsense.org/issues/3760
On that, cmb indicates he has done some testing and it is still not fixed. -
Cheers Phil
I have already commented on the bug report too, I just didn't want to get too 'chatty' on there, because it seems the folks on there have done some pretty advanced diagnostics and I didn't want to distract from the good work they were doing :)
-
Another round of fixes.
Next snapshot should have the missing piece for fixing this. -
I still can't seem to get this working on the 17th October, 11:27:45 version.
Have you had a chance to try it out ermal? Perhaps I am not configuring the Nat and Rules pages correctly?
M
-
This is not working for me and I'm using 2.2-BETA (amd64) built on Fri Oct 17 20:02:23 CDT 2014 FreeBSD 10.1-RC2
I have attached my LAN, NAT (Port Forwrd), Manual Outbound NAT Rules.
I have also captured packets on both my WAN, WAN2 and LAN interfaces. On my WAN2 and LAN I can see the Syn, and the Syn Ack packets however I don't see the ack packet. Also there are some retransmissions. When I capture packets on my WAN and filter for port 32400 the capture is blank which tells me that the packet is not being sent out the default gateway. I have attached the .pcap files here in the form of a .txt file if you would like to look at them in wireshark the extension just needs to be changed back to .pcap . Hope this helps
Thanks,
P.S. Not sure why I was trying to embed these images from my onedrive folder but it didn't seem to work so I had to add attachments.
[capture on LAN.txt](/public/imported_attachments/1/capture on LAN.txt)
[capture on wan2.txt](/public/imported_attachments/1/capture on wan2.txt) -
I think my problem is the same.
If someone has some spare time to read: https://forum.pfsense.org/index.php?topic=82944.0I am running:
Version 2.2-BETA (amd64)
built on Fri Oct 17 20:02:23 CDT 2014
FreeBSD 10.1-RC2I am available to test any solution and report back.
-
It's a known bug and the developers are working on it. Until then if this is a deal breaker you can try going back to 2.1.5 until the issue is resolved. That is what I'm doing.
-
I'm seeing the same issues on the current snapshot – I've worked around the issue with some sourcerouting and having an upstream system on one of the WAN links handle NATting for now. That works (firewall rules forcing a gateway, then having manual NAT rules disabling NAT).
It looked like using firewall rules to force the alternate gateway would make the multiWAN NAT rules start working correctly, but I didn't test that yet. It definitely adds another layer of config management to do this, so I eagerly await having this one squished :)
-
Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.
-
@cmb:
Don't change anything on your system trying to fix this, it's part of the packet filter that's currently broken in snapshots. It's slightly more correct now, as reply-to does at least return route correctly. But it's sending traffic with broken checksums, which still leaves it broken. Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.
It's just a little portion of the old home network, and thankfully the changes are easy backed out to test any fixes :)
Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.
-
Thanks a ton for the feedback that it's being worked on, aside from this particular snag, 2.2 is looking stellar for my usage.
Agreed - I'm new to pfSense, but I'm very impressed with the speed of development and the "get it right in the GUI" approach. I've been using OpenWRT for a few years and there is a real tendency to push any advanced configuration to the command line, leaving much of your intricate configuration hidden within the GUI. I think the approach pfSense takes seems much more sensible - right down for the meaningful descriptions of all parameters in within the GUI
-
@cmb:
Ermal's heading home from our hackathon in a few hours. He'll fix that when he gets back home later in the week.
Hi Ermal - have yo had a chance to take a look at this yet?
M
-
Please test next coming snapshot.
-
This works for me on IPv4 now with a kernel Ermal built with the fix that'll be in the next round of snapshots. Hopefully next snapshot run will be good (first one from the 30th should have it).
-
Thanks Ermal - Everything seems to be working great now :)
-
IPv4 is fixed here, still an issue with IPv6 and TCP but all the common cases confirmed working with today's snapshot.
-
IP4 is working for me now also. Thank you!
-
@cmb:
IPv4 is fixed here, still an issue with IPv6 and TCP but all the common cases confirmed working with today's snapshot.
I can confirm the issue with IPv6, but ICMP does not seem to work in my case. The rule below used to work on my 2.1 install. I have migrated my old config to a 2.2 test machine.
