Disable anti spoofing on an interface



  • Hello,

    Is is possible to disable antispoofing on an interface?
    If yes, how can this be done?

    Suppose, antispoofing is active on an interface, which it is by default in pfSense.
    Does the addition on a rule on that interface to allow a particular subnet override the antispoofing on that interface?

    Thank you.



  • Hello,

    Anyone has any idea?
    If I remove the line which says "antispoof for re1_vlan50" (re1_vlan50 is the interface name), and save the file, will this work?
    If yes, how can I make the change persist after reboot?

    Thanks for any help.



  • I tried to make the change in /tmp/rules.debug, but I think that after some time, the file is regenerated and overwrites the previous one.



  • OK. I'll try to give more information.

    I have 2 pfSense boxes connected via the Internet.
    Each one has 3 interfaces: LAN, WAN & OPT1
    There is an IPsec VPN between the 2 pfSense boxes.
    A WAN optimisation (WANOPT) appliance is connected to the OPT1 interface on each side.
    There is a UDP tunnel between the 2 WANOPT appliances.
    This UDP tunnel goes inside the IPsec tunnel.
    I use PBR (as a LAN rule) to redirect traffic going to the remote LAN into the WANOPT appliance.

    This is what I've observed after starting to ping a remote LAN machine from a local LAN machine:
    1. On reaching the local LAN interface, the ICMP echo request is properly redirected to the WANOPT appliance.
    2. The ICMP request goes inside the UDP tunnel.
    3. The UDP packets go into the IPsec tunnel.
    4. On the remote side, a tcpdump shows that the ICMP packet does come out of the WANOPT appliance and therefore the UDP tunnel.
    5. It then reaches the OPT1 interface of the remote firewall.
    6. It does NOT come out any interface!!!
    7. There's nothing in the log saying that the packet was dropped.
    8. I have an "Allow all protocols from any to any" rule on the OPT1 interface, for testing purposes.
    9. I also set an "Allow all protocols from any to any" rule on the IPsec interface, for testing purposes.

    What has happened to the packet?

    NB:
    1. On the remote side, when the ICMP packet comes out of the UDP tunnel, its source IP is that of the local LAN machine and its destination is that of the remote LAN machine.
    2. Is this packet considered a spoofed packet?

    Thank you for any help.



  • I found out that in order to make the changes in /tmp/rules.debug file permanent (as far as antispoofing is concerned), the file /etc/inc/filter.inc (around line 3105 in pfSense 2.1.4) should be modified.
    I did that on both local and remote pfSense boxes and rebooted them, but with no success, i.e., I am unable to ping the remote LAN machine from a local LAN host.

    Any help is very much welcome.



  • Don't edit the source, there's no need to change what's in the ruleset manually. Whatever is happening there has nothing to do with anti-spoofing. If it's not getting logged as being blocked, it's going somewhere or trying to go somewhere. Usually where traffic is misdirected in such cases, it's because you have a wrong IPsec P2 matching the traffic and it pulls it in, or the system's routing table in general is wrong.



  • Chris,

    Thanks a lot for replying.

    Please find some more details below:
    1. Local LAN subnet: 10.6.0.0/16
    2. Remote LAN subnet: 192.168.6.0/24
    3. Local OPT1 subnet: 10.50.0.0/16
    4. Remote OPT1 subnet: 192.168.50.0/24
    5. IPsec Phase 2 entries on local pfSense: 10.6.0.0/16 -> 192.168.6.0/24 AND 10.50.0.0/16 -> 192.168.50.0/24
    6. IPsec Phase 2 entries on remote pfSense: 192.168.6.0/24 -> 10.6.0.0/16 AND 192.168.50.0/24 -> 10.50.0.0/16

    Do you find anything wrong?

    PS: For the sake of testing, I enabled logging for all packets entering the OPT1 interface and I can confirm that, on reaching the OPT1 interface of the remote firewall, the packet is ALLOWed into the OPT1 interface as shown in the log.

    Routing table pf remote pfSense is attached.




  • I started a ping from the local machine having IP 10.6.2.10/16 to 192.168.6.106/24.
    See attached log extract of the remote pfSense.
    NB: Interface SILVERPEAK is the OPT1 interface.
    We can see that the ICMP request packet is ALLOWed into the remote OPT1 interface.




  • A clog from the shell on the remote pfSense gives the following output, after the ping is started on the local machine:

    Jul 17 21:27:50 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 0, length 64
    Jul 17 21:27:52 fw2 pf: 00:00:01.885014 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 1, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:52 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 2, length 64
    Jul 17 21:27:52 fw2 pf: 00:00:00.358395 rule 5/0(match): block in on re2: (tos 0x0, ttl 128, id 1110, offset 0, flags [DF], proto TCP (6), length 40)
    Jul 17 21:27:52 fw2 pf: 192.168.6.106.54118 > 23.214.64.109.443: Flags [R.], cksum 0x4fe4 (correct), seq 1951833685, ack 1897326514, win 0, length 0
    Jul 17 21:27:53 fw2 pf: 00:00:00.628387 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 2, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:53 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 3, length 64
    Jul 17 21:27:54 fw2 pf: 00:00:01.148349 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 3, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:54 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 4, length 64
    Jul 17 21:27:55 fw2 pf: 00:00:00.874917 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 4, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:55 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 5, length 64
    Jul 17 21:27:56 fw2 pf: 00:00:01.011050 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 5, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:56 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 6, length 64
    Jul 17 21:27:57 fw2 pf: 00:00:00.989951 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 6, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:57 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 7, length 64
    Jul 17 21:27:58 fw2 pf: 00:00:00.995826 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 7, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:58 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 8, length 64
    Jul 17 21:27:59 fw2 pf: 00:00:01.031938 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 8, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:27:59 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 9, length 64
    Jul 17 21:28:00 fw2 pf: 00:00:00.971443 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 9, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:28:00 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 10, length 64
    Jul 17 21:28:01 fw2 pf: 00:00:01.040452 rule 159/0(match): pass in on re0: (tos 0x0, ttl 62, id 10, offset 0, flags [none], proto ICMP (1), length 84)
    Jul 17 21:28:01 fw2 pf: 10.6.2.10 > 192.168.6.106: ICMP echo request, id 43547, seq 11, length 64

    I believe this does confirm that the ICMP request is well received on the OPT1 interface on the remote pfSense.



  • Please find attached a network diagram of the setup.