Proper way to find out where it all goes wrong is tcpdump on the 192.x.x.x network interface on both ends. Start at the pfsense and see if the packets go thru the tunnel as it should. Then check the return packet back. You need to tell your 192.x.x.x interface not to use your default gw. Centos manual shows exactly how to do this with multiple interfaces.
-lsf man. 4. jan. 2016, 23:36 skrev Decker, Ryan C. <rdec...@siena.edu>: > What do your iptables rules look like? I know you said you temporarily > stopped firewalld but worth a look anyway. > > Run: > > iptables -nvL > iptables -t nat -nvL > > then just for good measure: > > sysctl net.ipv4.ip_forward > > When it comes to firewalld i almost never run it on anything important. You > can install a systemd unit file for iptables by installing > iptables-services. > > Then after running: > systemctl stop firewalld; systemctl disable firewalld; systemctl enable > iptables; systemctl start iptables > > You can manage rules the old fashioned way by either editing > /etc/sysconfig/iptables or by running iptables directly and using > iptables-save > /etc/sysconfig/iptables. > > Ryan > > On Mon, Jan 4, 2016 at 3:42 PM, Espen Johansen <pfse...@gmail.com> wrote: > > > Try to add; > > ip route add 192.168.1.0/24 via 192.168.1.1 > > and > > ip route add 192.168.2.0/24 via 192.168.1.1 > > > > -lsf > > > > man. 4. jan. 2016, 21:08 skrev Sébastien La Madeleine < > > slamadele...@toolsoft.ca>: > > > > > Hi Robert, > > > > > > I just tried the following advice and it did not improve my situation. > > > > > > Unless there is more to it than just changing those parameters... > > > > > > Thanks, > > > > > > Sébastien La Madeleine > > > B.Sc., M.Sc. Informatique > > > TooLSoft.ca > > > 514-827-8665 > > > > > > On 2016-01-04 2:43 PM, Robert wrote: > > > > you need to enable ip forwarding in the kernel on cento to filter or > > > use both interfaces. > > > > http://centoshowtos.org/network-and-security/ip_forward/ > > > > > > > > > > > > Robert > > > > > > > > > > > > > > > >> On Jan 4, 2016, at 12:59 PM, Sébastien La Madeleine < > > > slamadele...@toolsoft.ca> wrote: > > > >> > > > >> Hello, I've searched high and low to elucidate this one but so far > > > nothing has queued me in the right direction so I'm turning to the > > network > > > experts herein. > > > >> > > > >> Let me give you a little bit of context and expose my problem. Feel > > > free to ask if more details are needed. > > > >> > > > >> I have 2 pfSense firewall in 2 separate locations. > > > >> > > > >> Both access the internet directly. An IPSec tunnel has been created > > so > > > that the services of both locations are accessible on both sides. > > > >> > > > >> I have multiple servers on both sides both Windows and Linux. > > > >> > > > >> Some servers have a single nic, others have 2 nics, one in the LAN > and > > > one on the WAN for direct service access purposes. > > > >> > > > >> Both ends are in separate subnets. > > > >> > > > >> Site A: > > > >> 192.168.1.0/24 > > > >> pfSense 192.168.1.1 > > > >> > > > >> Site B: > > > >> 192.168.2.0/24 > > > >> pfSense 192.168.2.1 > > > >> > > > >> The tunnel is up and running. Since both sites are for the same > > > project, both firewalls have a "pass all IPV4" in the IPSec rules. > > > >> > > > >> 192.168.1.2 (Windows server with single nic) can ping 192.168.2.2 > > > (Windows server with single nic) and vice-versa. > > > >> 192.168.1.3 (Windows server with 2 nics) required a new route (route > > > add -net 192.168.2.0/24 gw 192.168.1.1) to be able to ping 192.168.2.2 > > > and the ping works both ways. > > > >> > > > >> Here comes my problem. > > > >> 192.168.1.4 is a CentOS 7 machine. It has 2 nics, one on the LAN > > > (192.168.1.4) and one on the WAN. The default gateway for this machine > > is > > > obviously on the WAN side. > > > >> > > > >> Try as much as I can, I never managed to add a route that would > allow > > > traffic to be routed to 192.168.2.0 through 192.168.1.1. > > > >> > > > >> route -n add -net 192.168.2.0/24 -m 100 gw 192.168.1.1 > > > >> > > > >> route -n: > > > >> Kernel IP routing table > > > >> Destination Gateway Genmask Flags Metric Ref Use > > > Iface > > > >> 0.0.0.0 167.114.xxx.xxx 0.0.0.0 UG 100 0 0 > > > eno1678003 > > > >> 167.114.xxx.xxx 0.0.0.0 255.255.255.248 U 100 0 0 > > > eno1678003 > > > >> 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 > > > eno3355929 > > > >> 192.168.2.0 192.168.1.1 255.255.255.0 UG 0 0 0 > > > eno3355929 > > > >> > > > >> I tried many a thing and exhausted my bag of tricks (and Google's as > > > far as I am concerned) > > > >> > > > >> I temporarily deactivated FirewallD on the CentOS machine and > nothing > > > changed. > > > >> > > > >> Here's the output of the ping: > > > >> > > > >> ping 192.168.2.2 > > > >> PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. > > > >> From 192.168.1.1: icmp_seq=1 Redirect Host(New nexthop: > 192.168.1.2) > > > >> From 192.168.1.1 icmp_seq=1 Redirect Host64 bytes from 192.168.2.2 > : > > > icmp_seq=1 ttl=126 time=80.9 ms > > > >> From 192.168.1.4 icmp_seq=2 Destination Host Unreachable > > > >> From 192.168.1.4 icmp_seq=3 Destination Host Unreachable > > > >> From 192.168.1.4 icmp_seq=4 Destination Host Unreachable > > > >> From 192.168.1.4 icmp_seq=5 Destination Host Unreachable > > > >> > > > >> Now seing the redirect, I tried to deactivate it, here's the result: > > > >> > > > >> sysctl -w net/ipv4/conf/eno3355929/accept_redirects=0 > > > >> sysctl -w net/ipv4/conf/eno3355929/send_redirects=0 > > > >> > > > >> PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. > > > >> From 192.168.1.4 icmp_seq=1 Destination Host Unreachable > > > >> From 192.168.1.4 icmp_seq=2 Destination Host Unreachable > > > >> From 192.168.1.4 icmp_seq=3 Destination Host Unreachable > > > >> From 192.168.1.4 icmp_seq=4 Destination Host Unreachable > > > >> > > > >> ifconfig output: > > > >> > > > >> eno1678003: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > > >> inet 167.114.xxx.xxx netmask 255.255.255.248 broadcast > > > 167.114.xxx.xxx > > > >> inet6 fe80::250:::xxxx prefixlen 64 scopeid 0x20<link> > > > >> ether 00:50:56:xx:xx:xx txqueuelen 1000 (Ethernet) > > > >> RX packets 4546 bytes 347948 (339.7 KiB) > > > >> RX errors 0 dropped 0 overruns 0 frame 0 > > > >> TX packets 498 bytes 124662 (121.7 KiB) > > > >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > > >> > > > >> eno3355929: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > > >> inet 192.168.1.4 netmask 255.255.255.0 broadcast > > 192.168.1.255 > > > >> inet6 fe80::250:::xxx prefixlen 64 scopeid 0x20<link> > > > >> ether 00:50:56:xx:xx:xx txqueuelen 1000 (Ethernet) > > > >> RX packets 4908 bytes 392770 (383.5 KiB) > > > >> RX errors 0 dropped 0 overruns 0 frame 0 > > > >> TX packets 979 bytes 129316 (126.2 KiB) > > > >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > > >> > > > >> lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 > > > >> inet 127.0.0.1 netmask 255.0.0.0 > > > >> inet6 ::1 prefixlen 128 scopeid 0x10<host> > > > >> loop txqueuelen 0 (Local Loopback) > > > >> RX packets 136 bytes 153735 (150.1 KiB) > > > >> RX errors 0 dropped 0 overruns 0 frame 0 > > > >> TX packets 136 bytes 153735 (150.1 KiB) > > > >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > > >> > > > >> > > > >> What really stumps me is that everything is fine on the Windows side > > of > > > the servers... That CentOS machine is the first that really won't > work. > > > >> > > > >> I tought about moving the machine behind the pFsense, but the move > has > > > not been approved by the application supplier so, for now, not an > option. > > > >> > > > >> The setup is quite simple so I'm assuming it's just a little bit of > > > configuration that is missing, and my Google foo is not elevated enough > > to > > > find it. I hope you guys can help me figure it out... > > > >> > > > >> -- > > > >> Sébastien La Madeleine > > > >> > > > >> _______________________________________________ > > > >> pfSense mailing list > > > >> https://lists.pfsense.org/mailman/listinfo/list > > > >> Support the project with Gold! https://pfsense.org/gold > > > > _______________________________________________ > > > > pfSense mailing list > > > > https://lists.pfsense.org/mailman/listinfo/list > > > > Support the project with Gold! https://pfsense.org/gold > > > > > > _______________________________________________ > > > pfSense mailing list > > > https://lists.pfsense.org/mailman/listinfo/list > > > Support the project with Gold! https://pfsense.org/gold > > _______________________________________________ > > pfSense mailing list > > https://lists.pfsense.org/mailman/listinfo/list > > Support the project with Gold! https://pfsense.org/gold > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
