make sure you reboot the cents server after that change, if it is still having issues centos has some routing issues, so you need to have both cards setup with ip and gateway and only ONE default route or gateway which will be the wan in your case then you need to configure next hops and route to the other one.
https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-networkscripts-static-routes.html <https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-networkscripts-static-routes.html> that way any services on either card can forward to each other and route between them. Robert > On Jan 4, 2016, at 2:08 PM, Sébastien La Madeleine <slamadele...@toolsoft.ca> > wrote: > > 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
